CVE-2024-42080

What it actually does

Potential invalid memory address access in rdma_restrack_clean() when dereferencing a kern_name pointer set to a module's KBUILD_MODNAME after the owning module has unloaded without deleting the rdma_restrack_entry.

Why it matters to the business

Unexpected system crashes or instability on Linux systems using RDMA, leading to downtime for workloads relying on high-performance networking or storage.

How an attack unfolds

An attacker with local access triggers creation of an RDMA completion queue via ib_create_cq() in a loadable module, causes the module to exit without cleanup, then invokes rdma_restrack_clean() to dereference the now-invalid kern_name address, resulting in a kernel fault.

How to fix it

Upgrade the Linux kernel to a version containing commit 8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5 or later; remove the obsolete restrack code paths used for forgotten PD release detection.

How to confirm the fix worked

Verify the kernel source contains commit 8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5; confirm absence of the kern_name assignment to KBUILD_MODNAME in ib_create_cq() and removal of related cleanup logic.

Typical attack path

1. Obtain local access on a Linux system with RDMA support
2. Load a module that registers an rdma_restrack_entry via ib_create_cq()
3. Unload the module without deleting the restrack entry
4. Trigger restrack cleanup path to access freed module name string

How to detect it

Review kernel logs for oops/panic messages mentioning rdma_restrack_clean or invalid address access during module unload; inspect for restrack entries left after module exit in RDMA subsystems.

What your security team should do

• Apply the referenced kernel commit or distribution update immediately on all RDMA-enabled systems
• Prioritize patching in environments with frequent module loading/unloading or custom ULPs
• Monitor for kernel oops or panic logs referencing rdma_restrack after module unload events