CVE-2024-53215

What it actually does

Failure to destroy percpu counters initialized in svc_rdma_proc_init() when register_sysctl() returns NULL leaves residual nodes in the percpu_counters list; on module unload with CONFIG_HOTPLUG_CPU this triggers a page fault in percpu_counter_destroy_many, otherwise causing memory leakage.

Why it matters to the business

Kernel oops or memory leaks on systems using RDMA RPC transport can cause sudden crashes or gradual resource exhaustion, disrupting high-performance storage, networking, or compute workloads; the issue has been public for over a year with no known active exploitation.

How an attack unfolds

An attacker with local privileges loads the svcrdma module, forces register_sysctl() to fail, then unloads the module; under CONFIG_HOTPLUG_CPU this triggers the use of an invalid percpu counter pointer during task teardown, resulting in a kernel page fault.

How to fix it

Update the Linux kernel to commit a12c897adf40b6e2b4a56e6912380c31bd7b2479 or later; rebuild and reboot with the patched kernel; for Ubuntu hdf5 packages apply the listed backports (1.8.11-5ubuntu7.1 or 1.8.16+docs-4ubuntu1.1) if they pull in the kernel fix.

How to confirm the fix worked

Confirm the running kernel contains commit a12c897adf40b6e2b4a56e6912380c31bd7b2479 via uname or git describe; attempt module load/unload under register_sysctl failure conditions and verify no percpu_counter oops occurs; check for absence of memory leaks via slabinfo or kmemleak after repeated load/unload cycles.

Typical attack path

1. Obtain local access or code execution on a Linux system with the vulnerable svcrdma module
2. Trigger RPC RDMA transport registration that returns NULL from register_sysctl()
3. Unload the svcrdma kernel module
4. Trigger task teardown or CPU hotplug events to invoke percpu_counter_destroy_many on stale entries

How to detect it

Search kernel logs for oops traces referencing percpu_counter_destroy_many, mmdrop, and svc_rdma_proc_cleanup; inspect dmesg or journalctl for RPC RDMA registration/unregistration sequences followed by page faults; correlate with module unload events in audit logs.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems exposing RDMA transports
• Monitor for kernel oops containing percpu_counter_destroy_many during module unload
• Test module unload paths in staging environments that match production CONFIG_HOTPLUG_CPU settings
• Review downstream dependents of the affected kernel tree for inherited exposure