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

[Greg Dahlman <dahlman () gmail com>]

I am sure there is some reason I can't find what I am going to mention
implemented, so sorry if this has been discussed before.

Both socket(2) and socket(3p) both 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.

If this experiment worked, and could be extended to other legacy and
obscure PF and AFs, it would provide an interface that would help LSMs,
container runtimes, admins etc... IMHO LD_PRELOAD isn't an option right now
just because it is so easy to abuse, especially with user namespaces, it is
currently trivial to get elevated privileged processes from any normal user
on most systems.

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

And 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

While there are mitigations in place that make it more unlikely, the
capabilities in that bounding set are a risk. IMHO Capabilities is less
preferable to say limiting socket() for a PF/AF to a UID/GID. To be clear I
am suggesting a PF/AF targeted application, using credentials(7) before
allocating the FD or whatever method works.

Depending on the interface chosen, it may also allow developers to remove
access or add access quickly and iterate faster and remove some of the
friction of migrating to another solution.

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)