CVE-2023-54048

What it actually does

Race condition in RDMA/bnxt_re driver allows completion handlers to be scheduled after QP destruction while CQs remain active, enabling concurrent execution of destroy_cq and poll_cq that can free a CQ while poll_cq still runs, resulting in use-after-free and kernel panic.

Why it matters to the business

Repeated driver load/unload or RDMA QP operations on affected systems can trigger kernel panics and system reboots, causing downtime for workloads relying on bnxt_re hardware; prevalence in container operators increases exposure across clusters.

How an attack unfolds

An attacker triggers repeated QP creation, destruction, and CQ polling operations via userspace RDMA applications or driver unload sequences; the race window allows poll_cq to execute after CQ free, producing the panic shown in the bnxt_re_poll_cq stack trace. No named threat actors or ransomware campaigns are associated.

How to fix it

Upgrade to a kernel containing commit b79a0e71d6e8692e0b6da05f8aaa7d69191cf7e7; for percona-server-mongodb-operator packages update to 1.20.1-r1 (Chainguard/Wolfi variants). Reboot after kernel update and verify bnxt_re is no longer scheduling completions post-destroy_qp.

How to confirm the fix worked

Confirm the presence of commit b79a0e71d6e8692e0b6da05f8aaa7d69191cf7e7 in the running kernel; reproduce the original load/unload loop test and verify absence of the bnxt_re_poll_cq panic stack trace.

Typical attack path

1. Obtain local or container access sufficient to load/unload bnxt_re or issue RDMA QP verbs
2. Create and immediately destroy a QP while CQ work remains queued
3. Allow ib_cq_poll_work to schedule bnxt_re_poll_cq after the CQ has been freed
4. Trigger the concurrent destroy_cq path leading to panic

How to detect it

Search kernel logs and dmesg for the exact panic call trace containing bnxt_re_poll_cq, __ib_process_cq, and ib_cq_poll_work; correlate with timestamps of bnxt_re module load/unload or RDMA QP destroy events.

• bnxt_re_poll_cq+0x14a/0x620 [bnxt_re]
• Call Trace: bnxt_re_poll_cq
• __ib_process_cq+0x57/0x190 [ib_core]
• ib_cq_poll_work+0x26/0x80 [ib_core]
• Snippet of kernel panic while doing bnxt_re driver load unload in loop

What your security team should do

• Prioritize kernel upgrades on systems exposing bnxt_re RDMA devices
• Apply the fixed percona-server-mongodb-operator 1.20.1-r1 packages where used
• Monitor kernel logs for bnxt_re related panics during driver or container lifecycle events
• Restrict unprivileged RDMA access until patches are deployed