From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 622BB39890F for ; Thu, 26 Mar 2026 07:39:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774510787; cv=none; b=kLB8dBS+ahrymrONNDJKa3sh1u9r0Y8ML+6WAnPWV01jrb7lCkxVZnNgguyIYBu4XK0hcwLE5neTsGHyomLVk/c3c7PPsHDXEgXQZerAdqkoz1hyC8W9vMfdC6Ix6K3Rljmft8tvLVU8VTuQ0CiXOL1O0f0yvWBL0omt7Y64p7Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774510787; c=relaxed/simple; bh=y3DyWiP+AmvSd4U8VoMQInTjQYw7Y35L4JVy0+of41g=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=pvXdNl0UZCD6EYihrW0hVURqNWurIrXzIvR/kCO7fV7W8MxbTm+Qzdjkun4cNKIjnpvGgIJcIyRU5BfZId3MKhFUygfeY3Wm3Nh4gM2E9S/qr7/AQOYY2DQeBQGOzljo2A0CBFlYCRsahtaUYmd0VvEOPlVIRDBthTcMJDROVmU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t6q6j9o6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="t6q6j9o6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C567CC116C6; Thu, 26 Mar 2026 07:39:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774510787; bh=y3DyWiP+AmvSd4U8VoMQInTjQYw7Y35L4JVy0+of41g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=t6q6j9o6aqtk4vZBgXpNT8WER61sfuKTlODZmdi5GC266RSkMo976N58V/f7qa2Xn S24GablbxEJW0AaNaGM7rg9jtCJSXCJ5PYkS0HOYtLLaxbqLkt9rn9Mgiy8JdgCBK/ EmTu0phqmLRYQBAYcuxKoI6i0Ybs4SGJsduTp+Cn1pVvFAjABOrD8p3kQZt784Ni6+ /DO1dYw8vUMU3BrVvZFBfNwAAZSBMfu81OKBpS3HxyM6923TkJqZQbYAAeKQ/Z7qxc EwW0jy6AWQNW+elnJo5QdurKal3M9eeT9zPAsKOHH/k0WvklRBDMOcMXn7heQJzBvk sf9alp1hr89nQ== Date: Thu, 26 Mar 2026 16:39:44 +0900 From: Masami Hiramatsu (Google) To: David Laight Cc: Andrew Morton , "Masami Hiramatsu (Google)" , Petr Mladek , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/2] lib/vsprintf: Fixes size check Message-Id: <20260326163944.1a7e83e7c1a70202c1a05deb@kernel.org> In-Reply-To: <20260325102039.79afa79a@pumpkin> References: <177440550682.147866.1854734911195480940.stgit@devnote2> <20260324220458.3ca2bfeb393eedb5cc7ff52d@linux-foundation.org> <20260325102039.79afa79a@pumpkin> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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 Wed, 25 Mar 2026 10:20:39 +0000 David Laight wrote: > On Tue, 24 Mar 2026 22:04:58 -0700 > Andrew Morton wrote: > > > On Wed, 25 Mar 2026 11:25:06 +0900 "Masami Hiramatsu (Google)" wrote: > > > > > Here is the 4th version of patches to fix vsnprintf(). > > > > > > - Fix to limit the size of width and precision. > > > - Warn if the return size is over INT_MAX. > > > > > > Previous version is here; > > > > > > https://lore.kernel.org/all/177410406326.38798.16853803119128725972.stgit@devnote2/ > > > > > > In this version, do clamp() the width and precision before checking it and > > > accept negative precision[1/3] and add Petr's Reviewed-by[2/2]. > > > > AI review has flagged a couple of possible issues: > > https://sashiko.dev/#/patchset/177440550682.147866.1854734911195480940.stgit@devnote2 > > I'd guess there are exactly 0 places where a negative precision is passed > to "%.*s" - if there were any someone would have complained about the > output being missing. > Checking all 759 cases grep -r '".*%.*\.%*s.*"' found will be tedious. > But pretty much all are 'namelen'. I also verified and found only one suspicious usage which can pass a negative precision. diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index d2c7b1090df0..1f90775ea8a8 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -2224,7 +2224,7 @@ void i915_request_show(struct drm_printer *m, rcu_read_lock(); timeline = dma_fence_timeline_name((struct dma_fence *)&rq->fence); drm_printf(m, "%s%.*s%c %llx:%lld%s%s %s @ %dms: %s\n", - prefix, indent, " ", + prefix, max(0, indent), " ", queue_status(rq), rq->fence.context, rq->fence.seqno, run_status(rq), Thanks, > > In any case worst thing should be a panic if the code hits an invalid > address before finding a '\0' byte - probably unlikely anyway. > > I'd fix it, but try to stop it being backported. > > David -- Masami Hiramatsu (Google)