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

From: Nicolas Schier

Date: Wed Jan 28 2026 - 04:08:37 EST


On Tue, Jan 27, 2026 at 01:59:15PM -0700, Nathan Chancellor wrote:
> 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@xxxxxxxxxxxxxx/
>
> > 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@xxxxxxxxxxx>
>
> 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?
>

I'm happy to take it (v2) for kbuild-fixes this week.
Thanks!

--
Nicolas