Re: CVE-2026-31431: CopyFail: linux local privilege scalation

[Greg Dahlman <dahlman () gmail com>]

> From the admin side, here are my concerns.

LD_PRELOAD and capabilities are not a great option due to user
namespaces, lsm limitations, etc....

Review this qualys submission from last year for an example.
https://www.openwall.com/lists/oss-security/2025/03/27/6

You should expect any UID (even nobody) to be able to gain the
privileges in their bounding set, and because some packages like LXD
remove some of the protections from above etc...

Note the Bounding set on the install user on Ubuntu 26.04:

     $ cat /proc/$$/status | grep ^CapBnd
     CapBnd: 000001ffffffffff
     $ capsh --decode=000001ffffffffff
0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore


Both socket(2) and socket(3p) define and allow for EACESS, IMHO it
would be far more maintainable to leverage credentials(7) vs
capabilities(7) in this case, and it may offer a backwards compatible
solution.

I am not talking about requiring a device file with permissions, just
a method of setting constraints based on uid/gid etc... Especially as
these mechanisms often could never justify namespace support, I think
it cannot depend on the permissions of a device file as they may not
be able to view it.

I am sure that there is a reason no one has taken advantage of:
https://man7.org/linux/man-pages/man3/socket.3p.html
       The socket() function may fail if:

       EACCES The process does not have appropriate privileges.

Or: https://man7.org/linux/man-pages/man2/socket.2.html
       EACCES Permission to create a socket of the specified type
and/or protocol is denied.

IMHO, ideally the kernel would provide a (ideally subuid/subgid
compatible) method of limiting PF/AF sockets outside of the core.
Right now it is almost impossible to run with reduced privileges, and
in the oci/k8s world there are no methods to enforce even syscomp
rules, because the commands/containers/upstream don't allow for a
bounding set.  The CRIs like runc or crun for example can be invoked
directly, and as mutation etc... is up stream they will accept any
seccomp profile or no profile at all,

Currently it is trivial to gain almost any capability in a users
bounding set, and while userns limits the scope to the user, if you
are gating on capabilities(), you should expect any adversarial code
(browser plugin, container image etc..) to be able to gain it.

IMHO finding someway to depend on credentials(7) is a far more
maintainable step:
https://man7.org/linux/man-pages/man7/credentials.7.html

I realize that this isn't an option for AF_INET, etc... but those have
namespace support, it would seem that the cost for checking uid/gid
before doing file descriptor allocation /proc/*/fd in cases like this
would be easier.

This doesn't solve the splice() issue, but would allow us admins to
harden our systems and as EAFNOSUPPORT and EACCES are existing
standards, returning EACCES isn't a huge change.


On Sat, May 2, 2026 at 7:56 AM Demi Marie Obenour <demiobenour () gmail com> wrote:
> On 5/1/26 23:54, Eric Biggers wrote:
> > On Sat, May 02, 2026 at 03:35:58AM +0000, Eric Biggers wrote:
> > > So the idea would be something along the lines of:
> >
> > And just to make sure no one gets the wrong impression: just because
> > there seem to be ways in which the attack surface of AF_ALG could/should
> > be reduced doesn't mean that userspace should keep using it (or even
> > worse, start to use it).  Fixing programs like iwd needs to proceed
> > concurrently, so that eventually (some years down the line) the problem
> > can finally be fully solved by removing AF_ALG from the kernel source.
> >
> > - Eric
>
> Can AF_ALG be emulated using LD_PRELOAD?  That would allow it to be
> eliminated from the kernel much more quickly, as one would not need
> to get rid of all of its existing users.  It would even work for those
> who need AF_ALG because of closed source binaries, who otherwise will
> have no alternative other than running an old kernel in a VM.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)