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: <aXnFzbuV6oQJD_Sj@levanger>
Date: Wed, 28 Jan 2026 09:16:13 +0100
From: Nicolas Schier <nsc@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Ethan Zuo <yuxuan.zuo@...look.com>, masahiroy@...nel.org,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kbuild: Fix permissions of modules.builtin.modinfo

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@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?
> 

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

-- 
Nicolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ