Linux kernel keyctl: use-after-free reading a key type name during module unload

Impact

A local user calling KEYCTL_DESCRIBE can race a privileged unload of a key-type module (the report uses AF_RXRPC=m) and make kasprintf() read the type name from module memory that has already been freed, faulting in string() or potentially reading freed kernel memory. The practical effect on a GPU node is a host kernel oops that takes the whole machine down with every tenant job on it, and a drain-and-reboot to recover a node whose GPUs were mid-training. Exploitation needs both a local account and a concurrent module unload, which is a privileged action and not something a tenant triggers on a steady-state node, so this is a low-probability race rather than a routine escalation path. The fix holds key->sem for reading across the kasprintf() so retirement cannot free the name mid-format.

Who can reach it

Local authenticated user with keyctl access (any tenant shell or container without seccomp blocking keyctl), racing a privileged key-type module unload. Not reachable from the network.

What to do

Pick up the stable kernel containing the keyctl key->sem fix (five stable branches have backports, listed in the record) and reboot each node; there is no runtime mitigation other than not unloading key-type modules such as af_rxrpc on a live node, which already avoids the race. Plan it with the next routine kernel maintenance rather than an emergency window - the race needs a privileged module unload to be in flight.

References

Related entries

• Xen through 4.12.x - passed-through PCI devices left able to DMA into host memory after being handed to an untrustedCVE-2019-18424 · Xen through 4.12.x - passed-through PCI devices left able to DMA into host memory after being handed to an untrusted…Medium
• Xen on AMD-Vi (AMD IOMMU) - ACPI IVMD unity-map page permissions: Xen honours ACPI-described IOMMU unity mappings butCVE-2021-28694 · Xen on AMD-Vi (AMD IOMMU) - ACPI IVMD unity-map page permissionsMedium
• Xen on AMD-Vi - IOMMU page mapping permissions: Second of the XSA-378 IOMMU page-mapping issues on AMD-Vi. IncorrectCVE-2021-28695 · Xen on AMD-Vi - IOMMU page mapping permissionsMedium
• Xen on AMD-Vi - IOMMU page mapping permissions: Third of the XSA-378 AMD-Vi mapping issues. Same practical consequenceCVE-2021-28696 · Xen on AMD-Vi - IOMMU page mapping permissionsMedium
• Linux kernel (arch/x86/kvm): A failed RSM leaves the vCPU's SMM flag and the MMU role out of sync, so KVM resolves aCVE-2021-47230 · Linux kernel (arch/x86/kvm)Medium
• VMware ESXi: AD-integrated ESXi grants full host admin to any member of a re-created "ESX Admins" groupCVE-2024-37085 · VMware ESXiMedium