Linux Kernel CVE-2026-99224

Concrete prerequisites: (1) the kernel must provide the relevant key type from a LOADABLE module rather than built-in - the description explicitly cites AF_RXRPC=m - since a built-in (=y) type is never unregistered/freed and cannot trigger the fault; (2) a local attacker must hold at least View permission on a key of that module-provided type to call KEYCTL_DESCRIBE; and (3) a concurrent unregister_key_type() via the module's exit path (af_rxrpc_exit) must occur and win the race against the describing task inside the window between kvasprintf()'s two formatting passes. Limiting factors that reduce realistic risk: exploitation is local only (AV:L), the race window is narrow (AC:H), the triggering module unload is itself a privileged operation not controlled by an unprivileged attacker, and systems that compile the affected key-type modules as built-in are not exposed.

This is a genuine but constrained local kernel issue, not an internet-facing emergency. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.0) is internally consistent with the description: AV:L reflects that the attacker must call keyctl locally, AC:H reflects the narrow race window between kvasprintf()'s two formatting passes and a concurrent module unload, and PR:L reflects that the describing task only needs View permission on the key. The real-world priority signals are modest and non-conflicting: vuln.today assigns 'this_week' (not act_now/emergency), there is no CISA KEV listing, no EPSS score is supplied, and no proof-of-concept or exploit reference is present - only the fix commits. So exploitation status is 'no public exploit identified at time of analysis.' One honest caveat on the vector itself: the vulnerable read occurs in the unprivileged KEYCTL_DESCRIBE path (PR:L is defensible), but reliably WINNING the race depends on a concurrent unregister_key_type()/module unload, which is itself a privileged action (typically CAP_SYS_MODULE) rather than something an unprivileged attacker controls - this makes dependable self-contained exploitation materially harder than PR:L alone suggests. The impact labeling also deserves scrutiny: this is a use-after-free READ of freed module storage, so the realistic outcomes are a kernel oops (availability/DoS, well evidenced by the supplied Oops/page-fault trace) and possible disclosure of freed kernel memory to userspace, rather than memory corruption with integrity impact. Overall: treat as a scheduled kernel-update item, consistent with the 'this_week' label, not a drop-everything issue.

A local user holding View permission on a key whose type is supplied by a loadable module (the description cites a kernel built with AF_RXRPC=m) issues KEYCTL_DESCRIBE; the kasprintf() path saves key->type->name and completes its first formatting pass, then stalls on a GFP_KERNEL allocation. If a concurrent, privileged unload of that module (af_rxrpc_exit → unregister_key_type) retires the key and frees the module during that window, the second formatting pass reads the freed name from released module storage, faulting in string() and oopsing the kernel (or leaking stale freed memory into the userspace describe buffer). No proof-of-concept or exploit code is referenced in the available data, and the high attack complexity reflects this tight timing requirement.