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

[Joshua Hahn]

On Fri, 18 Jul 2025 16:39:59 +0800 kernel test robot <lkp@xxxxxxxxx> 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)