linux-kernel - Re: [PATCH] drm/i195: Fix format string truncation warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMj1kXEgfykaf9oB4_tuAQqwXDN+NLy_Hb_+RnQmeicVgKt0bA@mail.gmail.com>
Date: Sun, 9 Nov 2025 19:00:34 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Tvrtko Ursulin <tursulin@...ulin.net>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org, 
	Jani Nikula <jani.nikula@...ux.intel.com>, 
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Rodrigo Vivi <rodrigo.vivi@...el.com>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, intel-gfx@...ts.freedesktop.org, 
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] drm/i195: Fix format string truncation warning

On Sat, 8 Nov 2025 at 01:27, Tvrtko Ursulin <tursulin@...ulin.net> wrote:
>
>
> On 07/11/2025 16:42, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@...nel.org>
> >
> > GCC notices that the 16-byte uabi_name field could theoretically be too
> > small for the formatted string if the instance number exceeds 100.
> >
> > Given that there are apparently ABI concerns here, this is the minimal
> > fix that shuts up the compiler without changing the output or the
> > maximum length for existing values < 100.
>
> What would be those ABI concerns? I don't immediately see any.
> > drivers/gpu/drm/i915/intel_memory_region.c: In function ‘intel_memory_region_create’:
> > drivers/gpu/drm/i915/intel_memory_region.c:273:61: error: ‘%u’ directive output may be truncated writing between 1 and 5 bytes into a region of size between 3 and 11 [-Werror=format-truncation=]
> >    273 |         snprintf(mem->uabi_name, sizeof(mem->uabi_name), "%s%u",
> >        |                                                             ^~
> > drivers/gpu/drm/i915/intel_memory_region.c:273:58: note: directive argument in the range [0, 65535]
> >    273 |         snprintf(mem->uabi_name, sizeof(mem->uabi_name), "%s%u",
> >        |                                                          ^~~~~~
> > drivers/gpu/drm/i915/intel_memory_region.c:273:9: note: ‘snprintf’ output between 7 and 19 bytes into a destination of size 16
> >    273 |         snprintf(mem->uabi_name, sizeof(mem->uabi_name), "%s%u",
> >        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >    274 |                  intel_memory_type_str(type), instance);
> >        |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> > ---
> > Cc: Jani Nikula <jani.nikula@...ux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@...el.com>
> > Cc: Tvrtko Ursulin <tursulin@...ulin.net>
> > Cc: David Airlie <airlied@...il.com>
> > Cc: Simona Vetter <simona@...ll.ch>
> > Cc: intel-gfx@...ts.freedesktop.org
> > Cc: dri-devel@...ts.freedesktop.org
> >
> > This is unlikely to be the right fix, but sending a wrong patch is
> > usually a better way to elicit a response than just sending a bug
> > report.
> >
> >   drivers/gpu/drm/i915/intel_memory_region.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_memory_region.c b/drivers/gpu/drm/i915/intel_memory_region.c
> > index 59bd603e6deb..ad4afcf0c58a 100644
> > --- a/drivers/gpu/drm/i915/intel_memory_region.c
> > +++ b/drivers/gpu/drm/i915/intel_memory_region.c
> > @@ -271,7 +271,7 @@ intel_memory_region_create(struct drm_i915_private *i915,
> >       mem->instance = instance;
> >
> >       snprintf(mem->uabi_name, sizeof(mem->uabi_name), "%s%u",
> > -              intel_memory_type_str(type), instance);
> > +              intel_memory_type_str(type), instance % 100);
> It's a theoretical issue only since there is no hardware with a double
> digit number of instances.
>
> But I guess much prettier fix would be to simply grow the buffer.
>

Whatever works for you - I don't really understand this code anyway.

> Also, hm, how come gcc does not find the mem->name vsnprintf from
> intel_memory_region_set_name?
>

The optimizer works in mysterious ways, I guess. I cannot explain why
I am the only one seeing this in the first place, but the warning
seems legit to me.