CVE-2023-54274

What it actually does

Race condition in RDMA/srpt allows srpt->mad_agent to hold an error pointer instead of NULL or a valid pointer during concurrent srpt_add_one/srpt_remove_one execution; subsequent ib_unregister_mad_agent call dereferences the error value, producing a NULL pointer dereference and kernel oops.

Why it matters to the business

Linux systems using RoCE or InfiniBand hardware can experience sudden kernel crashes and reboots when RDMA devices are registered or unregistered, leading to unplanned downtime and loss of RDMA-dependent workloads.

How an attack unfolds

An attacker with local access triggers simultaneous device add and remove paths (for example by rapid hot-plug, driver reload, or LAG reconfiguration) to hit the narrow window where mad_agent contains an error value; the missing validity check then causes ib_unregister_mad_agent to dereference invalid memory and panic the kernel.

How to fix it

Upgrade the Linux kernel to a version containing commit 8ec6acdb9b6a80eeb13e778dfedb5d72a88f14fe or later; apply the vendor-supplied package update for the affected distribution; reboot after installation.

How to confirm the fix worked

Confirm the running kernel contains commit 8ec6acdb9b6a80eeb13e778dfedb5d72a88f14fe; verify that srpt_unregister_mad_agent now performs an explicit valid-pointer check before calling ib_unregister_mad_agent; test device registration/unregistration under load to ensure no oops occurs.

Typical attack path

1. Obtain local code execution or shell on a Linux host with RDMA/srpt and RoCE hardware
2. Trigger concurrent srpt_add_one and srpt_remove_one execution paths
3. Force the mad_agent pointer to retain an error value during the race window
4. Cause srpt_remove_one to call ib_unregister_mad_agent on the invalid pointer
5. Trigger kernel NULL pointer dereference and system crash

How to detect it

Search kernel logs and crash dumps for oops messages referencing _raw_spin_lock_irqsave, ib_unregister_mad_agent, srpt_unregister_mad_agent, or srpt_remove_one; correlate with bnxt_re or RoCE driver activity around the time of the panic.

• BUG: kernel NULL pointer dereference.*ib_unregister_mad_agent
• srpt_unregister_mad_agent+0x93/0xd0
• Workqueue: bnxt_re bnxt_re_task

What your security team should do

• Prioritize kernel updates on all systems exposing RDMA interfaces
• Monitor vendor security advisories for backported fixes in supported LTS kernels
• Restrict local access and limit RDMA device hot-plug privileges until patched
• Include kernel oops logs containing ib_srpt and bnxt_re symbols in incident response playbooks