From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 18D653E1CFA for ; Tue, 31 Mar 2026 16:12:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774973544; cv=none; b=E1fCH93abTTJcEt9bG5CahiRJkPM84fjRDvCwTUYLvvGcQRP8o/NoP2D0vBcNaKuWAYggJNwN5ewIyqvNyeMaUvFWQBVEx99QziM64+mVYkvU9CCXWDvTcU1YY/pIAv88WqjkBhm1ZOzoijvzaCkkP9l+70gYjwekruH3d9Leck= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774973544; c=relaxed/simple; bh=gOGUmeNIoXRqJbi6Z4ekpdKE88S6jmppRospdEK0l2k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qPTAqopy8F5qdJkZfW9sdHri9ahlmivt6gydWDLCnHvy8Tyk0q78UhfEA6zuqw9HdeSpqkhKR7IgoDh7/VIOPF+bdnlpmzinhyZFIHgW1DTs/OivL0HQnLJP2nBrkkrj4dxOJwRvtAho+uINSnBUqDdqRx7M6qub2hpWFPhsbzY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=d4FNx7v+; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="d4FNx7v+" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-486fe655187so76879085e9.2 for ; Tue, 31 Mar 2026 09:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1774973541; x=1775578341; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0WUGTFWgxKARg5sqF9yQJFWo/eGJgqysdJmrkxdi9aI=; b=d4FNx7v+Onyq+XrOkfLu8jsv8Eb+JL5IAfyFqcHs56wVZ+2haGq/+C428I1jWLmGiz i9tp20Q5ceEJb6SsbPFVc/EtZ/HoR0sM11aJGqHh9mVvbLcEykhgD04SFwzG0fTpyA0K EyBtMmSoPNyTlhKw14v2KiJIDIJ4s2FtJXBbsQbPOCh9P+4icoXlPjeCSZnqubIUADbs cQafroG+jf45bwrEOQHMgupstw8XVDmfN85ZUBF/g86zIjUoCv1Xn+M2yJLy0yTWiUj3 tgfWunjlzb7Qxf6HHDB5td63rk6bFtdnKGcl1/hTtl/y+lg2ocMXih0UYvmqA5atadQG 23SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774973541; x=1775578341; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0WUGTFWgxKARg5sqF9yQJFWo/eGJgqysdJmrkxdi9aI=; b=QwoS27voI50/2kABbbD39cSQ4Lc/Rgh74Js7mYI/2NrmFkWC3Q5FYt0gQXaW4WOeTu Pu6yg9by/kO1wWd4RDrkQXmGnUdOykHOCpB1x7IEqrU1wkC9waFVXk1oS5qe7rZWoVp0 pcTPeZZNR1kxUXC0wUirm/JPCu81EzPOPa2V0nXPZtxHIORPdem2h3CMMe07JepaOA9V 0jsAEaeWmxK+zImCF3eXlwJeJ1t2CgP1Hhh/QNwsZQXBSp9eZ1aDNZFy7ElWx3XRoivC wfOoaeK7w2GvzSbLrYhPNmAqpBHmeXazDPbmkyYz1h4/u42lVMd3pOUBxBdKyA6bJ4S7 UTZA== X-Forwarded-Encrypted: i=1; AJvYcCV6OQ1P5uCCVNtzh/NadF3XpZG1Doixmw+ijWdMam9e0iTKZCDvmQa/gkpF16Ybx/skWY8/ButLt1jcw8k=@vger.kernel.org X-Gm-Message-State: AOJu0YxBRldWfQKqhUIPRDWxTWqJKak/GJNMZ7d7jhrrHjgi7PdhEr1F jOb+yPsBlmdIsY1w0cN80+P5bhA3QNHhovMH2FccCwl7VmpqZyNl5X4b2/e1N+RsEyk3VDZ/sz/ i8TeRwMk= X-Gm-Gg: ATEYQzw/3xnwdDwOT2UPdRApTbKPielfpfNmdzRaqfpBT1k4pN4/99wMINBfSkEkPQe l46KTdAclkncZnX/OyHtmXjb+YE+Mb2gkOSwt6MH3mlrk4pv7Q0K0P6oF2QTNb050g1tANgWDdl eD1vkpk6vavBed9xomk3pqwGow5fl5VnbR7Ii42RQUJAsBDMKmvgrSFipJ3U0Kc5Wg6RRKVCYT0 c/sN+CP0N98myqxGy+JViivMpERO47utsdmxX3HAx8QuBOvngvbEXhh4MwPYbuH8hfkpieNTsSc FKd0VOllVfv6o5qc1R0einNJPCXgamEGL8krxa+tcJjOzIXU8lAY0nJ8022+Ym+oPICfr+HbN/H DfMFtn84K+ofyWYzHiNnXck7JSVo/Rx3qp2Y6T7Q9o6mjMZDPLtlXohEUXZNye/yCG7oqH7bNKa +d1nW6frfrOqy+nbu5dxNyjnIZaA== X-Received: by 2002:a05:600c:8b2a:b0:485:2c61:9457 with SMTP id 5b1f17b1804b1-48727d62cedmr310146135e9.10.1774973541261; Tue, 31 Mar 2026 09:12:21 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887e80a6ebsm55975515e9.6.2026.03.31.09.12.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 09:12:21 -0700 (PDT) Date: Tue, 31 Mar 2026 18:12:18 +0200 From: Petr Mladek To: David Laight 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: References: <20260324224940.50508-1-objecting@objecting.org> <20260324224940.50508-4-objecting@objecting.org> <20260331163522.74467342@pumpkin> 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-Disposition: inline In-Reply-To: <20260331163522.74467342@pumpkin> 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 fied_width <= INT_MAX instead of SHRT_MAX. 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/