Re: [PATCH] sysctl: add CAP_SYS_ADMIN check to panic/ctrl-alt-del sysctls

[Aleksa Sarai]

On 2026-04-17, wooridge <yurenwang152@xxxxxxxxx> wrote:
> Several kernel sysctls that control critical system behavior use
> proc_dointvec() as their handler with mode 0644, but proc_dointvec()
> does not perform any capability checks. In a user namespace where a
> process has uid 0, the VFS layer allows writes based on the file
> permission bits (0644), enabling unprivileged modification of critical
> kernel parameters.

"unprivileged" and "uid 0" are not really compatible terms.

More importantly, these kinds of check-permissions-at-write checks are
actually quite weak because of setuid binaries -- you can always
redirect the output of a setuid binary to a file to bypass these kinds
of checks. A very classic example is mempodipper (CVE-2012-0056) but the
recent "CrackArmor" bug (in particular CVE-2026-23268) is an even more
obvious example. For those reasons, if an attacker can get access to an
O_RDWR handle to a sysctl file, you're long since screwed.

For reference, proc_dointvec_minmax_sysadmin() was added in commit
bfdc0b497faa ("sysctl: restrict write access to dmesg_restrict") but
there are two things to consider:

 1. This code was added before mempodipper was discovered and so the
 understanding around why these kinds of access controls are not that
 useful was not as developed as it is today.

 2. The change was primarily focused on trying to avoid a loophole when
 people were running with non-userns containers and had access to
 writable /proc/sys. This is considered wildly insecure by modern
 standards and would not be considered a security hole worthy of fixing
 today. (Most container runtimes use user namespaces, which block this,
 and most container runtimes also bind-mount /proc/sys as read-only
 which also block this.)

So, in my view this logic was somewhat flawed back then but makes
absolutely no sense today and should not be propagated to other sysctls
because it just gives a false sense of security.

> Affected sysctls: kernel/panic, kernel/panic_on_oops, kernel/panic_on_warn, kernel/ctrl-alt-del

I also want to point out that the files you mentioned aren't even the
juiciest targets -- kernel.core_pattern gives you free root code
execution on the host if you can write to it.

-- 
Aleksa Sarai
https://www.cyphar.com/

Attachment: signature.asc
Description: PGP signature