From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D178E3B7773 for ; Wed, 25 Mar 2026 12:05:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774440329; cv=none; b=i+VNaA1Jw9YCYQkC/RsC6K9fQFUbotkcVcyIiQbj63bf6qTaXEY5nXmKYYXrRYJemM0TKYKgphJKk0dMGBIi3WsIeyJM2Ly2ohdB+3fCcr00e1qQvg2xZt/0Y+CW1gtIPYBw01YXeZ7cZC08OC21f979H0apDpTEKSK1xHkrSVY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774440329; c=relaxed/simple; bh=8X0c2WSb2VFIdyEoYmjI0DT0NChWOuTp/hJaB6CNcbg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=A4HoJAEOevjBj950dQ9/P/8M6xIwq+VpOI2vafCgQPZXHrGl6aDC17l4b9NzJkACnhq2z3KdnbsL5O/3PGZs7BsCAVyMojRTgaZQWrhMp4pcKwN+kaXrTEs2ENRanAMz4tU3WZu7oOBtmZlQTr5ehH3cXaO7nc/482qPDBimFuc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nSKR2t2Q; arc=none smtp.client-ip=198.175.65.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nSKR2t2Q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774440329; x=1805976329; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8X0c2WSb2VFIdyEoYmjI0DT0NChWOuTp/hJaB6CNcbg=; b=nSKR2t2QGkBo8BIOMzIQ2gclIkCQY46eQd4dJa3s3oc5+ASXv/dbBaHp RhEMX/uKLYFT8JxqjFIiEBMv8Hsc3CVFuCqVBz16nwpzQ7Yw/Yz1t/n3L bp1/PJIpiqQoVRYXH92YUfavx+sRLn9jOadk7k6sii39TokVZ4oVY3cgC G4sM8wCpgOZu8qNsCU831pYBuQ0JCQyKGty6uXWcT9z4ahMQzPDY40sA4 OW9zKtKPBsJdtr1T+HZbmIHo7t3Rx7giZ5z3stwKlsboVmqm8N6qjDQCN AuEm6QwDuUt1UUbr5fp1GRclWE/uixROr/s3I4s2Ge0t1BIqeUXyDQrix A==; X-CSE-ConnectionGUID: Vhh8xdRnTuSNP7KNyTkYZw== X-CSE-MsgGUID: WcrZZtfDR2u7PDNW/pZNcA== X-IronPort-AV: E=McAfee;i="6800,10657,11739"; a="75496418" X-IronPort-AV: E=Sophos;i="6.23,140,1770624000"; d="scan'208";a="75496418" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2026 05:05:28 -0700 X-CSE-ConnectionGUID: mAGHKFmpSB6iAxrf770aoA== X-CSE-MsgGUID: sznmo0hcS02d6dyM+FmL+g== X-ExtLoop1: 1 Received: from dalessan-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.245.32]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2026 05:05:26 -0700 Date: Wed, 25 Mar 2026 14:05:24 +0200 From: Andy Shevchenko To: Josh Law Cc: Petr Mladek , Steven Rostedt , Rasmus Villemoes , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] lib/vsprintf: assorted bug fixes Message-ID: References: <20260324224940.50508-1-objecting@objecting.org> 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: <20260324224940.50508-1-objecting@objecting.org> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Tue, Mar 24, 2026 at 10:49:36PM +0000, Josh Law wrote: > Four small fixes found during an audit of lib/vsprintf.c: > > 1. bstr_printf() fails to advance the args pointer past a > pre-rendered pointer string when the output buffer is full, > corrupting all subsequent output. > > 2. vbin_printf() writes end[-1] unconditionally when NUL-terminating > a pointer string, which is an OOB write when size is zero. > > 3. vsscanf() uses s16 for field_width but assigns from skip_atoi() > which returns int, silently truncating large widths to negative > and aborting parsing. > > 4. format_decode() is missing a (u8) cast on the second lookup into > the format_state table, allowing a negative array index on > signed-char platforms. These all needs a good review. And I think binary printf() might have a bit different rules on how to propagate the pointer in the buffer. To me these might fix something or might break something or do nothing (like in patch 4) due to lack of expertise in the area. So, I am skeptical about accepting that series, sorry. But I leave it to others to decide, not giving any tag here. -- With Best Regards, Andy Shevchenko