In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
When cur_qp isn't NULL, in order to avoid fetching the QP from
the radix tree again we check if the next cqe QP is identical to
the one we already have.
The bug however is that we are checking if the QP is identical by
checking the QP number inside the CQE against the QP number inside the
mlx5_ib_qp, but that's wrong since the QP number from the CQE is from
FW so it should be matched against mlx5_core_qp which is our FW QP
number.
Otherwise we could use the wrong QP when handling a CQE which could
cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are
the only QPs in our driver whereas the QP number inside mlx5_ib_qp
doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP
CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21
RSP: 0018:ffff88810511bd60 EFLAGS: 00010046
RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a
RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10
R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000
R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0
FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0
Call Trace:
<TASK>
? __die+0x20/0x60
? page_fault_oops+0x150/0x3e0
? exc_page_fault+0x74/0x130
? asm_exc_page_fault+0x22/0x30
? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
__ib_process_cq+0x5a/0x150 [ib_core]
ib_cq_poll_work+0x31/0x90 [ib_core]
process_one_work+0x169/0x320
worker_thread+0x288/0x3a0
? work_busy+0xb0/0xb0
kthread+0xd7/0x1f0
? kthreads_online_cpu+0x130/0x130
? kthreads_online_cpu+0x130/0x130
ret_from_fork+0x2d/0x50
? kthreads_online_cpu+0x130/0x130
ret_from_fork_asm+0x11/0x20
</TASK>
Security readout for executives and security teams
Plain-English summary
A flaw in the Linux mlx5 RDMA driver can associate a completion event with the wrong queue pair, leading to a kernel null-pointer crash. Systems using mlx5 RDMA are the likely concern, particularly traffic involving queue pairs 0 or 1. The supplied CVSS rating is 8.8, but the public description directly demonstrates a crash rather than data theft or modification.
Executive priority
Treat this as a high-priority availability risk for mlx5 RDMA infrastructure, not an emergency for every Linux system. Rapidly identify exposed RDMA hosts and patch critical systems through supported distribution channels. Escalate where a kernel crash could interrupt storage, clustered computing, or other essential services. Current sources do not support claiming widespread or active attacks.
Technical view
mlx5_poll_one() compares a firmware-supplied CQE queue-pair number against the wrong software field. A false match can preserve an incorrect cur_qp while processing a completion, causing invalid kernel memory access in mlx5_ib_poll_cq(). The correction compares against the firmware-facing mlx5_core_qp number. The issue is especially noticeable for QPs 0 and 1, where the two identifiers differ.
Likely exposure
Exposure is concentrated in Linux systems actively using the mlx5_ib RDMA driver and affected kernels, rather than all Linux hosts. RDMA deployments using queue pairs 0 or 1 appear most susceptible. The supplied version data is ambiguously encoded, so organizations should confirm affected and fixed package versions with their Linux distributor instead of relying on the listed numbers alone.
Exploitation context
The CVSS vector describes adjacent-network reachability, low complexity, no privileges, and no user interaction. However, the bundle contains no KEV listing and no cited evidence of active exploitation or a public exploit. The demonstrated consequence is a kernel null-pointer dereference. Practical reachability and any confidentiality or integrity impact are not established by the supplied description.
Researcher notes
The root cause is an identifier-domain mismatch: the CQE carries a firmware QP number, but the reuse check examined the mlx5_ib_qp number. This can incorrectly retain cur_qp and process a CQE through the wrong object. The trace confirms a supervisor-mode read fault at address 0x12. No CWE is assigned, and the bundle does not establish controlled code execution.
Mitigation direction
Apply a vendor-supported kernel update incorporating the appropriate linked stable-kernel fix.
Confirm distributor guidance for affected and fixed package versions before scheduling remediation.
Prioritize RDMA hosts where mlx5_ib is active, especially availability-critical compute, storage, and network infrastructure.
Use normal maintenance and reboot procedures so the updated kernel is actually running.
Validation and detection
Inventory running kernel versions on systems providing mlx5-based RDMA services.
Confirm whether mlx5_ib and RDMA workloads are active on each candidate host.
Map each kernel package to distributor advisories or the applicable stable-kernel fix commit.
After updating and rebooting, verify the running kernel matches the approved fixed package.
Review kernel logs for mlx5_ib_poll_cq faults, null dereferences, or related crashes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-22086 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
12Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.