From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (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 CBE983FF89D for ; Tue, 31 Mar 2026 15:35:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774971327; cv=none; b=aYzTPNGK7sKSmOERHIt7DR6HbI9ajeco8Kub99+eRL8HyNi73uCw1A4Dcq6sA5pYbjBHaokRvJovwIXTl0gGuPwazoGu84oaS+EF5x3eo6oCgAm4UwSeL0xXPIGgOXEbdf5XVvRqRBEKynnOAlJDdTP5Wwnq0+pGQXXxzqwl3dM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774971327; c=relaxed/simple; bh=Bb/edC7uQTcpKaB9r5np62LTVGQFYCsoWvlylsjxqmY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ktm5BmTrIOsBLYLTwaLdT41bfHOsimY8qjg42ia0aR/Ob/bT79Pw4FwYeUVmRuyGYQsbInnCJDoYkQqBA0xdUefW+ZBysUWKoiOSB9GvOroaAD4xOQ9brEzxTkShSJ4lcfGML69LCHbTztebxZviN0mB+aAlUfSKL4PsPdLXYqI= 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=R9odHOL3; arc=none smtp.client-ip=209.85.218.48 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="R9odHOL3" Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-b93698bb57aso1891866b.0 for ; Tue, 31 Mar 2026 08:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774971324; x=1775576124; 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=+9a4agORkhkSx3rU2z/Px04WA7D1RaJX2RMsnHMkVGg=; b=R9odHOL3ME6Pb9RieuF6WF7diJ5zxpQQFUX/DV9oRC6CzTjMgRjZzbgFL/UEcpnVeE 7VfFnmLD55cdTvJ3JgFA0g9tL9akUA9SpR+4aobQJ6H7thiAUBbB5+2GBuZUyfZYsufL HGWt5ON9DHOg9d3MlFGTq6NoAn6kyhCbQP9M8Jo4dBGGUHFSkCtmUKNK5XkilVugpITV iZ/JvWCzrPjeTvSRWCkcFO/+akPH1CLthaWks12BvjvXN/vbx2cql9KURw6PLfIgEjqw +fIHONG+9FSJL9iXEizQhUrkOV3l1jBFngYkrUA8acxQDEj59W0JvSWG2j7bfjs1Qg/6 7anw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774971324; x=1775576124; 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=+9a4agORkhkSx3rU2z/Px04WA7D1RaJX2RMsnHMkVGg=; b=VA8baoazNfP6uLVic1xllcvPTRBeu9Tbn4912tAARlFx75K+rKBdB+0+d2Tb4ZzC1Z SR36+cQ+j4tEDV+I518TFoq7qZOC7noMFLdYPsdGk1phNk7Tf4kloTuNsWeIoa/Hmi4L 7FMac7Wa9M+LEY10JP1HJ8/t2igmRN/XGouLXyOhn9YwIutz16L1qbaVcydFOwXRqSHd FcTZlPC8su1jHPwL23UyLUpJzi9eCnY/yf+9Zgvdj+KZ/VOMun677mmtrG3XgVu8OwxO TO3cHCQrrEwLx3NGC+1r8jvEG0koMtp6d2AP2EiMJteMQWv/nwHeMm4d3QKF9dsrwnzH 7Sog== X-Forwarded-Encrypted: i=1; AJvYcCWVIdRY8jw1qTkovYUMt2nqnjSSdtpjOw/WxUfs4bYIlg9Uzg0z2qRM7mtOo/3JUK/jXtNPScR53vx9ag0=@vger.kernel.org X-Gm-Message-State: AOJu0YydrqJ2URqSjfFBPdFQ/AOYhKa3nlKGsyX91ZJv/06JSdS+h2Ei ZD4L6TQu+wQw/zUQh+4NMErCdBsz5IpLvN7vVODSIWgYSadWfviK4j9Z X-Gm-Gg: ATEYQzwiF2YIqEOIc0a/YKSNrjJ/Fg+6nUuzSTp11SmAXp0MUUh7onyFmvSmGcyPOYK u888m5mbqV0Pwg8/OicVgOnpM2iQ9R7OrOr3I7dc3sm1B2+GjC1CSdU3S1B3HR11m0VlvQIh72A vhsKE9nIo+BeZ7MMHGoUhJODUaFt9lMAFTJtaIFc/fwKRz/EIQnC5Tax1eAgFD2lZBs8++b+oPK XwZq8R903m5X7WzL+efajJB41IjfwUwC8298XhxstpvA9Fu2f99qqX7QuMhMIYdDuiLbPTwORTc NUsJARwDDdzoBsdx2Nns+rbVCkLrh+eJL656kQqXnhEa2H2Z5drxb87uLyuxRJXRhrj9M/7G+gO jpCRpFa9blQS9QKNnp9/xVqzgwdPj3NqTC4gpnGJTSaq2JHCBOtQMeC/51BYh3IQT88OFS1/Chc QguZM/RMGOXDb8+ZGbGyrcgDwsLmV8o+RbeYryrEgxUkb6uvTMg5PkPjXpIAj5 X-Received: by 2002:a17:907:994e:b0:b9c:11ee:3c2f with SMTP id a640c23a62f3a-b9c11ee4064mr21050766b.1.1774971323836; Tue, 31 Mar 2026 08:35:23 -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 ffacd0b85a97d-43cf21ebef9sm29584081f8f.13.2026.03.31.08.35.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 08:35:23 -0700 (PDT) Date: Tue, 31 Mar 2026 16:35:22 +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: <20260331163522.74467342@pumpkin> In-Reply-To: References: <20260324224940.50508-1-objecting@objecting.org> <20260324224940.50508-4-objecting@objecting.org> 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 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, > 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). David