Linux kernel keyrings: out-of-bounds read in keyring_get_key_chunk() from unprivileged add_key(2)

Impact

For description-level chunks the keyring assoc-array walk advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup allocation — KASAN reports a slab out-of-bounds read. Reaching the description level requires two keys of the same type whose index hashes collide, which an attacker constructs deliberately, and the whole sequence runs from plain unprivileged add_key(2) with no capability required. On a shared GPU node that means any tenant with code execution can read adjacent slab memory or crash the host kernel, and the keyring subsystem is compiled into essentially every distribution kernel, so there is no configuration that opts out. The record rates confidentiality and availability high, locally.

Who can reach it

Local unprivileged user calling add_key(2) with a crafted pair of same-type keys — including a tenant inside a container, since add_key is not blocked by default seccomp profiles in every runtime. No authentication beyond code execution on the node.

What to do

Install a stable kernel carrying the fix and reboot each node; the patch is upstream on several branches (commits linked) and there is no configuration toggle that disables the keyring subsystem as a workaround. Plan a drain-and-reboot pass across the fleet rather than a mitigation, and prioritize nodes that hand untrusted tenants shell access.

References