CVE-2023-54028

What it actually does

The flaw causes a kernel oops when an error occurs during RDMA queue pair creation before rxe_init_task sets up the spinlock; the unwind path in rxe_cleanup_task then accesses the uninitialized spinlock.

Why it matters to the business

Environments relying on RDMA/RXE may experience unexpected kernel crashes and service interruptions during QP initialization failures; low EPSS and lack of KEV status indicate limited active exploitation risk but still require patching in affected Linux deployments.

How an attack unfolds

An attacker or workload triggers an error path in rxe_create_qp before rxe_qp_init_req completes, forcing rxe_cleanup and rxe_cleanup_task to dereference an uninitialized spinlock and panic the kernel.

How to fix it

Apply the upstream fix commit 3236221bb8e4de8e3d0c8385f634064fb26b8e38 or later stable kernels; upgrade lazydocker packages to 0.24.1-r4 where applicable.

How to confirm the fix worked

Confirm the fix commit is present in the kernel tree and verify that deliberate QP creation errors no longer trigger oops in rxe_cleanup_task.

Typical attack path

1. Induce error condition in rxe_create_qp prior to task initialization
2. Invoke error unwind calling rxe_qp_do_cleanup
3. rxe_cleanup_task dereferences uninitialized spinlock causing oops

How to detect it

Search kernel logs and crash dumps for oops messages referencing rxe_cleanup_task, non-static key registration, or rxe_qp_do_cleanup during RDMA operations.

• trying to register non-static key in rxe_cleanup_task
• rxe_cleanup_task
• rxe_qp_do_cleanup
• rxe_create_qp

What your security team should do

• Apply kernel updates containing the RXE fix in all RDMA-enabled systems
• Audit RDMA configurations for exposure to QP creation error paths
• Incorporate kernel panic monitoring for rxe-related symbols into detection playbooks