From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC24F2F4A15 for ; Wed, 1 Apr 2026 14:22:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775053381; cv=none; b=ZMPHphepDbr8MshRWS115ATcytNNMJRnUrKq4v9kbxfi+BEXSvBWXgevtrDPOmJ2yyrG1jS7VAD/F3WrGyQEzY02sV+IvdpjuVTn0UU9Jl5uHC0Z1wR996O8jbHfHtRvTvK9aa91+o9bXXVF13NMJRCWPuGMF3znz1ggAyIz6+8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775053381; c=relaxed/simple; bh=swyvKwh6735V90iyqu784dXx7FB5Mzo2jDr8sQXmTZo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=gQ5m3bjF08xYh9qR5/ivVpTkvhKV72A6dsv4fL3W/CiaEBgox16kUWWFkTtQgcf/lFj4JoJqg3owDq88beaqBnegHupAv3OzU2ozNAB0HMMdB4oe4V3rupiX2u0UYAaZ1IiCJY0QyoxEB1FalFLlSgmu9MTSrTkKWOanwWIRUXs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jLwrrwVB; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jLwrrwVB" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-48700b1ba53so64440825e9.1 for ; Wed, 01 Apr 2026 07:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775053378; x=1775658178; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=st+3wtuOODArSxlscREOghZGgM58m56IydtngObza0A=; b=jLwrrwVBvDNTwbvA8cTiK1/yQGqQEbSWYXtS8iQpQrn66BE7k9ZjsUz1FQ8P40wTal l7yldtZK0Ir1Z0cuV8E+KxlG2b+z8wa31j+xjmNBVcCPuYfpUW8VmzR2Pmjj/rB/XrB3 jcz6WeEHRjC6XfnIofcCEIHh+paWYk6qKyDtwGnpG+GW2sZ/RekrzxXPkng1Iv6uC7D3 PPIyuyeXfpaskjeW2PiA0wpoQSNXe04scFsQ2U42AmJTOaHfEqkqvZ94wgU/DzSyzEYJ vmnTJfgloFX50zOA3K+ylY46kOc3k75yY10B5HnGK432NVBz7ziTVxUX3yE8mYXAw4qT bVsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775053378; x=1775658178; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=st+3wtuOODArSxlscREOghZGgM58m56IydtngObza0A=; b=EWxKAtgB1Yb4/CvEmlnOV9UMd8GhEHqAD+OJK+ixglu45VNdpEU3tcvKZrpOxni5Jl JzIKtJUGqT+8fF/1PZuE12+QBxTlYzRPvV5koNkAdkxHZNOBBecFlDpExXXNTNFoYWb5 k4Vf2zUbdIRMKrxz52S081tGGzEylYq+k3V7X2sANY5Qewwgpy1cRn2INP4am8eUu+Qm mho1DsHL40JDIGYmRQ/KELnpilPcGrhckvQTi6kEAuRKL5iWH62EazfEBjk9IU9GCph7 KUPQeRb4jakVu94YLirKRRLPoVwITmp6crEP8ByXBNsQFFIgXFEkGVDhR4rcEs/+5OxE XleQ== X-Forwarded-Encrypted: i=1; AJvYcCWVweALnOADbFe1WrhiKPO07NUes5YyIPvb3HjomJw9ftNVtg0aaVM8jFprkMKpVSfPA5hoaHBTI3QbHuI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz3iS4/Bv7nYDTvS451mDnSZ2jUyN6O+JBiCqMCX5bCq0XsxYMx XCcT4K8TXPVQpBTIKHChxqjDpiAkeCmmB3jW7L55ZlB4XcIonTgH6ya4 X-Gm-Gg: ATEYQzzpcMLmulroIF5yJoJhvHO+GxQHZBECvWKCsmmG9IaGkj8E9fKMnELApNHz+Fh MVZV3flNBYzfBejwfXsbdhsWIdTPa5VRx6KWmTfRb2xRMDSeSSlTPg+UvqKRXZW/YiP64AaZij9 gpXOAevKvzd+g+zmu2Bo5zYhjTpMoDks5ISsLsuYx7p9WNK85fCMbsonRCJGfaJay3XVuWSqUHq 4H2yrGjf9R7R4IPH5QpZzD9p9xWQUCYhSO90uEr7QPu2ZkhBg8za9ixtKlK/4N1JqBxR98r5LTw beWhFBZpoFp4aSIN3UEtXUCkmRMxRgpSSQZ22CdKgmPczRG0d3wWsdvHHUt8EoYE4ikg2QJuE8b TjEwCgMHkjmNBjjoSx0eJojdyCDsllZCzNF4IC2p+/yhV5On82ts+RSK+HT97lB2iarhsrYnR6v vwEBz9anCDMUNqvV5gmKahBqLXlLzNgD+j6FdbIjxlbDrVuE16NHme/gyg7FH9 X-Received: by 2002:a05:600c:4747:b0:485:b6dd:5066 with SMTP id 5b1f17b1804b1-48883572102mr59840075e9.7.1775053378144; Wed, 01 Apr 2026 07:22:58 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4888a7165aasm1631995e9.14.2026.04.01.07.22.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2026 07:22:57 -0700 (PDT) Date: Wed, 1 Apr 2026 15:22:56 +0100 From: David Laight To: Petr Mladek Cc: Andy Shevchenko , Josh Law , Steven Rostedt , Rasmus Villemoes , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] lib/vsprintf: use int for field_width in vsscanf() Message-ID: <20260401152256.0b11e6c1@pumpkin> In-Reply-To: References: <20260324224940.50508-1-objecting@objecting.org> <20260324224940.50508-4-objecting@objecting.org> <20260331163522.74467342@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 31 Mar 2026 18:12:18 +0200 Petr Mladek wrote: > On Tue 2026-03-31 16:35:22, David Laight wrote: > > On Tue, 31 Mar 2026 16:31:50 +0200 > > Petr Mladek wrote: > > > > > On Wed 2026-03-25 14:00:17, Andy Shevchenko wrote: > > > > On Tue, Mar 24, 2026 at 10:49:39PM +0000, Josh Law wrote: > > > > > vsscanf() declares field_width as s16 but assigns it from skip_atoi() > > > > > which returns int. Values above 32767 silently truncate to negative, > > > > > causing vsscanf() to abort all remaining parsing. This is inconsistent > > > > > with struct printf_spec which uses int for field_width. > > > > > > > > Is the field_width an acceptable integer range by the specifications? > > > > > > I am not sure what is allowed by specification. Anyway, the code is > > > not ready for a bigger values, for example: > > > > > > case 's': > > > { > > > char *s = (char *)va_arg(args, char *); > > > if (field_width == -1) > > > field_width = SHRT_MAX; > > > > > > clearly expects signed short int range. > > > > > > I wonder if it might even open some backdoor. The code matching > > > as sequence of characters expects a defined field width, see > > > > > > > > > case '[': > > > { > > > [...] > > > /* field width is required */ > > > if (field_width == -1) > > > return num; > > > > > > The current code limits valid field width values to positive ones, > > I meant this code: > > /* get field width */ > field_width = -1; > if (isdigit(*fmt)) { > field_width = skip_atoi(&fmt); > if (field_width <= 0) > break; > } > > If we change the type of the local variable then the above check will > suddenly accept field_width <= INT_MAX instead of SHRT_MAX. But it is all broken anyway - consider "%65537[abc]". The test needs to be: if (field_width <= 0 || field_width > MAX_XXX) (and I doubt 32767 is a same limit anyway). (oh and skip_atoi() need to either saturate or stop consuming digits) David > > As a result, The above mentioned "case '[':" handling will suddely > allow to iternate over INT_MAX long string instead of SHRT_MAX. > > I doubt that there is any kernel code which would be affected > by this. But I do not want to risk it. > > > > aka SHRT_MAX which is clearly much lover than INT_MAX. And it might > > > prevent some out of bound access. > > > > Best Regards, > > > Petr > > > > > > > > > > Notwithstanding what the code actually does there is no point defining a > > local variable as a 'short' unless you really want arithmetic to wrap > > at 16 bits. > > All it does is force the compiler to keep adding code to fix the sign > > extension to 32 bits. > > Look at the object for anything other than x86 (or m68k). > > If you think that it is important enough, feel free to send > a patch. > > I not taking this patch from Josh Law, definitely! > > Best Regards, > Petr > > PS: Note that Josh Law seems to be an AI virtual person, see > https://lore.kernel.org/all/cbd0aafa-bd45-4f4d-a2dd-440473657dba@lucifer.local/ > > I am even not sure what to do with the other 3 patches. They look > correct. But I should not take patches with an unclear origin, see > https://lore.kernel.org/all/2f824be3-7b30-41c6-b517-de1086624171@kernel.org/ >