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

[Simon McVittie <smcv () debian org>]

On Sat, 02 May 2026 at 14:21:57 -0600, Greg Dahlman wrote:
> LD_PRELOAD and capabilities

These seem orthogonal, rather than being part of the same idea.

LD_PRELOAD is discretionary (cooperative) so it would only be useful if 
used in a design something like this:

- at the kernel level, AF_ALG just doesn't work (fails with a
  permission-related error), at least for unprivileged processes
- but in user-space, an opt-in LD_PRELOAD module intercepts the socket(),
  etc. calls for AF_ALG, and emulates the behaviour of current kernels
  by calling into a user-space crypto library

It can't be a security boundary, but it can be a mitigation for the 
regressions that a new security boundary (or complete feature removal) 
would otherwise cause, similar to the way LD_PRELOADs like aoss and 
padsp mitigated the regressions for older binaries when distro kernels 
disabled OSS audio.

Meanwhile capabilities are a way to let trusted, privileged processes 
have access to things that unprivileged processes do not, for example 
making AF_ALG available to a few system services that need it but not 
available to all of user-space.

> You should expect any UID (even nobody) to be able to gain the
> privileges in their bounding set

The kernel can distinguish between "CAP_FOO in the init namespace" and 
"CAP_FOO in any other userns" if it wants to, and some kernel features 
are already gated by having a capability in the init namespace 
specifically. For example CAP_SYS_ADMIN in the init namespace allows 
mounting block-device-backed filesystems like ext4, but CAP_SYS_ADMIN in 
a different userns only allows a few "safe" mount operations 
(bind-mounts, overlayfs, FUSE).

    smcv