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: <14ca1b28-df1d-4065-ad7a-97a3ff81a5a4@ursulin.net>
Date: Fri, 7 Nov 2025 20:48:51 +0000
From: Tvrtko Ursulin <tursulin@...ulin.net>
To: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org
Cc: Ard Biesheuvel <ardb@...nel.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 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.

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

Regards,

Tvrtko

>   
>   	mutex_init(&mem->objects.lock);
>   	INIT_LIST_HEAD(&mem->objects.list);