From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 67D793A8741 for ; Fri, 27 Mar 2026 10:12:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774606364; cv=none; b=J95yDpOq0j751HJdFsJN5moruDf1/S5vxBtWhAkDtjEYjkEDP1iO61OJafNWlX/7Tp6FVajGhVFispgP7ZSsar2dXg29ObdSQIFij/eBf/IVLZOnq4dhnssvl8gVOHVS5TizsO2/Qo12h/OdF34XxuPVrMLGZUoRlfNzBR+9DaY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774606364; c=relaxed/simple; bh=nl0DaHi4qf8Wd0m1mlUdSEq1bYl7Idonv6xdH2NY3u4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RnzDyOiS4y5r0w5tuNUDuDTfUR1MdIa46ttho8wSK6dRxOkvl60N9ucyXP+Al7mk7eRDqBl68qpx6fBHk4LbdFAODn19ngma7MiVkZWIRaBwoETIzWen5g1JIakiVhVDnYaNCsseda+VXUG0aEo9c0t0rkcmylZMyUqNpKBtLs4= 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=QBs4hrOV; arc=none smtp.client-ip=209.85.221.43 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="QBs4hrOV" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-43b949bf4easo1124964f8f.0 for ; Fri, 27 Mar 2026 03:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774606362; x=1775211162; 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=JkPzKwFnkpB+ukF0pnOl92tc2+SeNj5UEesqUdUm1WQ=; b=QBs4hrOV1kBEmNdO34nbkTfU74Ds/qNAb7OpYSU99eehCLXbV9v2+9tP9Dh74Ftu+0 lOW4nSgN2g3PXh1kWUxNPY3uLDZTqEiDnR0F4haqu+yfBW6UzbZBUTOCvJo4xgW4m0PT bIgyv+h/wMPWTFZsL8Hpbx0Qhqv/POpdca7XDkpP64Wy2lD6JEdbrywnfHvkaRDKlhbi est+QDJ5w+tjIm9fwAYe4V+bszcereY6XxKIBzOFgOaibjE5eAtSrsT4G3c6zwoYs5qv UICxj2i5LyENoIuRInDCZc0iDmZxsy7osa8zPHInG2laeJzfxpgE8I2fnoJ2OYAeKnAZ M2Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774606362; x=1775211162; 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=JkPzKwFnkpB+ukF0pnOl92tc2+SeNj5UEesqUdUm1WQ=; b=lHF1PHdLp5q7EfPrFnWp2Kw5/PH8j+TVMupq8XiToX6LIAeuwYl3XNRZqAHH7L6ZYy 2KWI5WpDEwqzM/aqRZqPUbtsHqhnOlmbub075aNXvpH01WYGz237AlSplpdN2CoA+wRl nhT01Z7uta15qzlOtVmKT2I3kXMsVaMNO+Z9/UZtpxy0+trM0tJfrQCcz4i83bcW24Re 33Aly28T5ldo/ZPYTe5Zxcb1or/AR1XoKBZHmBdKUXaUV/+RV/KExLY+5VM4ti9QEJSB VuoyqubQzXXUh73kK2m9w9L7Hq+IrGjHdx7t+hOl/znfoYl8n+HM/6AGdDuaWU3uPOC0 JToQ== X-Forwarded-Encrypted: i=1; AJvYcCUUD2w4rKYMAl1GU78ekKw8rbv/ufigX3FwixdZcugJXEzSPB8Vso3n2y/3mtJbLPoBbl5Zn8PsF8/FuN4=@vger.kernel.org X-Gm-Message-State: AOJu0YwBpKJpBi0/W8IVeq2MIagan6/otxntCkuW/lh5x6xTb0C2lF8+ Hh6QyKFFFebmUtAKJs4M5lWnpElLoWGmMi4EpfWKNBuPkR8muvF0H7aN0HZwOLsY X-Gm-Gg: ATEYQzxhCXNGSw/+z4DY08tYVOuDjZymP5m1LsTZApzR7TnW4KAMzpN2h4FKWujufVe AnJ8nNiFl3skqbqyhtBKhOZfkyx7XDkkaLrDZ84eBVfAhvEV9TMB64hAgLX/Psk/PPnOAF0NV5r XMCa9oj/d7Bg8uoOhtbUwqPmGnZxQh00Wn02h+OslgVV8HmRxKvNGRcNrmxyhmuT5Jib/2jdcvJ jRKpIIMoNSMqYU6ko3sGPcqgBPQYvmNH3AEzXxPvDRhKGdDgeIH3ZsuiV+nQ7wUEbpvFB+zrm8r w56CrC4wdKQZY3UzpA4mKPFRr93rac/Qs746iem/fUIh0fC6MhfWnysNwYkD6RM2ZL54/bKU+jm uVRZwX8D/BvURFiEhO8gSkO4pZ7T5Cd3UgpJG2jZxFKlNDWToWT2NkjZ+utHU2hGN4o6hvxS9PL /wufKyybGIc4xu1ZZY5nNSBA00SXnsYvb+cXAN8PhSyZH9cAl1FoMBaZ5axhnpgbPD X-Received: by 2002:a5d:5c84:0:b0:43b:40f6:36fb with SMTP id ffacd0b85a97d-43b97a9a483mr8515306f8f.31.1774606361445; Fri, 27 Mar 2026 03:12:41 -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-43b919df7e7sm13559219f8f.26.2026.03.27.03.12.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2026 03:12:41 -0700 (PDT) Date: Fri, 27 Mar 2026 10:12:39 +0000 From: David Laight To: "Masami Hiramatsu (Google)" Cc: Andrew Morton , 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: <20260327101239.76213a2c@pumpkin> In-Reply-To: <20260327162812.f657c7c01e1823fc874b2547@kernel.org> References: <177440550682.147866.1854734911195480940.stgit@devnote2> <20260324220458.3ca2bfeb393eedb5cc7ff52d@linux-foundation.org> <20260325102039.79afa79a@pumpkin> <20260326163944.1a7e83e7c1a70202c1a05deb@kernel.org> <20260326091212.5b370ff8@pumpkin> <20260327162812.f657c7c01e1823fc874b2547@kernel.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 Fri, 27 Mar 2026 16:28:12 +0900 Masami Hiramatsu (Google) wrote: > On Thu, 26 Mar 2026 09:12:12 +0000 > David Laight wrote: > > > On Thu, 26 Mar 2026 16:39:44 +0900 > > Masami Hiramatsu (Google) wrote: > > > > > 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. > > > > It is always called with a constant, in any case the string being output > > is constant so nothing nasty can happen. > > Since this function is not a static function, it can be called anywhere in > the module. So it is safer to check the indent is positive. That would have to be an out or tree module using a function that looks pretty specific to the i915 display code. Even as someone who has supported out of tree drivers I'd say that they get what they deserve. The snprintf() code itself won't break anything. David > > > I didn't even see any recursive/loop calls that indent by significant amounts. > > The code could use the more usual ("%*s", indent, ""), but it doesn't matter > > much - mostly just a shorter line. > > I think the current code looks a bit tricky and not clear what it does. > Maybe it is better to replace it with above usual usage. > > Thanks, > > > > > David > > > > > > > > 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 > > > > > > > > > >