linux-kernel - Re: mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63

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: <20250718152724.1206447-1-joshua.hahnjy@gmail.com>
Date: Fri, 18 Jul 2025 08:27:23 -0700
From: Joshua Hahn <joshua.hahnjy@...il.com>
To: kernel test robot <lkp@...el.com>
Cc: Xiu Jianfeng <xiujianfeng@...wei.com>,
	oe-kbuild-all@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63

On Fri, 18 Jul 2025 16:39:59 +0800 kernel test robot <lkp@...el.com> wrote:

>    mm/hugetlb_cgroup.c: In function 'hugetlb_cgroup_file_init':
> >> mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63 [-Wformat-truncation=]
>      829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
>          |                                            ^~
>    mm/hugetlb_cgroup.c:829:3: note: 'snprintf' output between 2 and 1656 bytes into a destination of size 64
>      829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 2087 bytes into a region of size between 32 and 63 [-Wformat-truncation=]
>      829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
>          |                                            ^~
>    mm/hugetlb_cgroup.c:829:3: note: 'snprintf' output between 2 and 2120 bytes into a destination of size 64
>      829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In theory,

#define MAX_CFTYPE_NAME = 64
sizeof(cft->name) = MAX_CFTYPE_NAME
sizeof(buf) = 32
sizeof(tmpl->name) = MAX_CFTYPE_NAME

But in practice there should never really be an overflow, since the longest
name so far "rsvd.max_usage_in_bytes" is 23 characters long and the longest
hugepage size string is "64KB" or "32MB"...

Unless someone makes a horrendously long name, I think we should be good.
With that said, char *mem_fmt only returns strings of up to 4 characters long.
Maybe we can shrink sizeof(buf) to be 4 and explicitly truncate the last
5 bytes (account for '.') of tmpl->name? I can spin something up.

Curious what others think though. Is this fix necessary? We really should
never overflow anyways.

Thank you Kernel Test Robot!
Joshua

Sent using hkml (https://github.com/sjp38/hackermail)