CVE-2023-54048
Unknown Unknown - Not Provided
Race Condition in Linux bnxt_re Driver Causes Kernel Panic

Publication date: 2025-12-24

Last updated on: 2025-12-24

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Prevent handling any completions after qp destroy HW may generate completions that indicates QP is destroyed. Driver should not be scheduling any more completion handlers for this QP, after the QP is destroyed. Since CQs are active during the QP destroy, driver may still schedule completion handlers. This can cause a race where the destroy_cq and poll_cq running simultaneously. Snippet of kernel panic while doing bnxt_re driver load unload in loop. This indicates a poll after the CQ is freed.Β  [77786.481636] Call Trace: [77786.481640] Β <TASK> [77786.481644] Β bnxt_re_poll_cq+0x14a/0x620 [bnxt_re] [77786.481658] Β ? kvm_clock_read+0x14/0x30 [77786.481693] Β __ib_process_cq+0x57/0x190 [ib_core] [77786.481728] Β ib_cq_poll_work+0x26/0x80 [ib_core] [77786.481761] Β process_one_work+0x1e5/0x3f0 [77786.481768] Β worker_thread+0x50/0x3a0 [77786.481785] Β ? __pfx_worker_thread+0x10/0x10 [77786.481790] Β kthread+0xe2/0x110 [77786.481794] Β ? __pfx_kthread+0x10/0x10 [77786.481797] Β ret_from_fork+0x2c/0x50 To avoid this, complete all completion handlers before returning the destroy QP. If free_cq is called soon after destroy_qp, IB stack will cancel the CQ work before invoking the destroy_cq verb and this will prevent any race mentioned.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-24
Last Modified
2025-12-24
Generated
2026-05-07
AI Q&A
2025-12-24
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's bnxt_re RDMA driver involves a race condition where completion handlers are scheduled after a Queue Pair (QP) has been destroyed. Hardware may generate completions indicating the QP is destroyed, but the driver might still schedule completion handlers for that QP. Since Completion Queues (CQs) remain active during QP destruction, this can cause a race between destroy_cq and poll_cq operations, potentially leading to kernel panics or crashes.


How can this vulnerability impact me? :

This vulnerability can cause kernel panics or crashes when the bnxt_re driver handles completions after a QP is destroyed. This instability can lead to system downtime, data loss, or degraded performance in systems using the affected RDMA driver, impacting reliability and availability.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring kernel logs for panic messages related to the bnxt_re driver, specifically looking for call traces involving bnxt_re_poll_cq and related functions indicating a poll after the CQ is freed. You can check the kernel log using commands like 'dmesg | grep bnxt_re' or 'journalctl -k | grep bnxt_re' to identify such errors.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that all completion handlers are completed before returning from the destroy QP function. Additionally, if free_cq is called soon after destroy_qp, the IB stack will cancel the CQ work before invoking the destroy_cq verb, preventing the race condition. Applying the updated Linux kernel patch that resolves this issue is also recommended.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart