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: <Z0YXaN1dHnEFUluE@bombadil.infradead.org>
Date: Tue, 26 Nov 2024 10:46:00 -0800
From: Luis Chamberlain <mcgrof@...nel.org>
To: Petr Pavlu <petr.pavlu@...e.com>
Cc: Song Chen <chensong_2000@....cn>, samitolvanen@...gle.com,
	da.gomez@...sung.com, linux-kernel@...r.kernel.org,
	linux-modules@...r.kernel.org
Subject: Re: [PATCH] kmod: verify module name before invoking modprobe

On Mon, Nov 18, 2024 at 01:54:14PM +0100, Petr Pavlu wrote:
> I'm however not sure about rejecting empty strings as is also done by
> the patch. Consider a call to request_module("mod%s", suffix) where the
> suffix could be empty to select the default variant, or non-empty to
> select e.g. some optimized version of the module. Only the caller knows
> if the suffix being empty is valid or not.
> 
> I've checked if this pattern is currently used in the kernel and wasn't
> able to find anything, so that is good. However, I'm not sure if
> request_module() should flat-out reject this use.

This patch also fails to pass a simple boot test with our Linux kernel
modules CI:

https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/linux-modules-kdevops-ci.md
https://patchwork.kernel.org/project/linux-modules/patch/20241110114233.97169-1-chensong_2000@189.cn/

For persistent results see this and download the tarball for results:

https://github.com/search?q=repo%3Alinux-kdevops%2Fkdevops-results-archive+is%3Acommit+%22linux-modules-kpd%3A%22&type=commits

So please boot test any future patch before posting and make sure its
based on modules-next:

https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/
modules-next

You can reproduce yourself with kdevops [0]:

make selftests-modules
make -j80
make bringup
make linux # it fails here with your patch applied
make selftests-baseline

For a more elaborate description of our CI setup:

https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/README.md

[0] https://github.com/linux-kdevops/kdevops

  Luis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ