linux-kernel - Re: [PATCH] kbuild: Fix permissions of modules.builtin.modinfo

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: <20260127205915.GA3856796@ax162>
Date: Tue, 27 Jan 2026 13:59:15 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Ethan Zuo <yuxuan.zuo@...look.com>
Cc: nsc@...nel.org, masahiroy@...nel.org, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kbuild: Fix permissions of modules.builtin.modinfo

Hi Ethan,

On Wed, Jan 28, 2026 at 03:23:23AM +0800, Ethan Zuo wrote:
> Currently, modules.builtin.modinfo is created with executable permissions
> (0755). This is because after commit 39cfd5b12160 ("kbuild: extract
> modules.builtin.modinfo from vmlinux.unstripped"), modules.builtin.modinfo
> is extracted from vmlinux.unstripped using objcopy. When extracting
> sections, objcopy inherits attributes from the source ELF file.

Ah, that explains why this is only visble after 39cfd5b12160, as
vmlinux.o was just a regular object file, whereas vmlinux.unstripped is
an executable. There was another patch submitted to address this issue
that did not explain that bit well:

https://lore.kernel.org/20251209-modinfo-executable-v1-1-ed0c553a4390@pengutronix.de/

> Since modules.builtin.modinfo is a data file and not an executable,
> it should have 0644 permissions. The executable bit can trigger
> warnings in Debian's Lintian tool.

I had asked on that previous submission what sort of issues could be
expected from being executable and warnings from tools is a reasonable
answer to that. Thanks for including that.

> Explicitly set the permissions to 0644 after generation.

Would it be better to do what the previous submission did and just
remove the execute bit via 'chmod -x'? That seems to be slightly more
common in the kernel (even though there are very few uses of 'chmod'
throughout Makefile instances) and seems to get at the issue a little
bit more. Not sure if the creation of these files respects umask, in
case someone had a more restrictive one, but that might be contrived.

> Fixes: 39cfd5b12160 ("kbuild: extract modules.builtin.modinfo from vmlinux.unstripped")
> Signed-off-by: Ethan Zuo <yuxuan.zuo@...look.com>

Nicolas, do you want to take this as a fix for 6.19 or should I take it
via kbuild-next for 6.20/7.0?

> ---
>  scripts/Makefile.vmlinux | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
> index cd788cac9d91..c5305619b1d3 100644
> --- a/scripts/Makefile.vmlinux
> +++ b/scripts/Makefile.vmlinux
> @@ -113,7 +113,8 @@ vmlinux: vmlinux.unstripped FORCE
>  # what kmod expects to parse.
>  quiet_cmd_modules_builtin_modinfo = GEN     $@
>        cmd_modules_builtin_modinfo = $(cmd_objcopy); \
> -                                    sed -i 's/\x00\+$$/\x00/g' $@
> +                                    sed -i 's/\x00\+$$/\x00/g' $@; \
> +                                    chmod 644 $@
>  
>  OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
>  
> -- 
> 2.51.0
>