CVE-2025-68379 Linux RDMA rxe SRQ Resize NULL Pointer Patch

A Linux kernel vulnerability identified as CVE-2025-68379 has been published to fix a null‑pointer dereference in the RDMA soft‑RoCE driver (rxe) that can crash the kernel when Shared Receive Queue (SRQ) resizing fails and callers invoke the modify operation twice in succession. The upstream stable patch addresses a latent race and lifecycle error where a failed resize can leave an SRQ’s internal queue pointer set to NULL; a subsequent ibv_modify_srq then dereferences that pointer when consulting the queue buffer’s index mask, producing a kernel oops. This vulnerability affects kernels shipping the in‑tree rxe driver until the stable commits are applied; vendors and downstream distributors have begun mapping the fix into their stable kernels and advisories.

Background / Overview​

Shared Receive Queues (SRQs) are an RDMA primitive used to share receive buffers across multiple queue pairs. The rxe driver implements a software RoCE endpoint for testing and environments that do not have hardware RDMA NICs. Because SRQs and their backing queues are allocated and resized dynamically, the driver must carefully maintain invariants about the queue pointer and buffer metadata (for example, the ring buffer’s index mask) through create, resize and destroy operations.
CVE‑2025‑68379 arises from an error path in the SRQ resize sequence: a failed resize can cause the helper that maps SRQ attributes into internal structures to set the SRQ’s queue pointer to NULL, and a follow‑up modify operation can then assume the queue pointer is valid and read fields beneath it — specifically the queue’s buffer index_mask — causing a NULL pointer dereference and kernel crash. Multiple vulnerability trackers and the OSV entry summarize the defect and link to the upstream fix.

---

Technical anatomy: what went wrong​

The code paths involved​

The bug centers on three logically connected pieces of rxe code:

• The SRQ attribute conversion helper (rxe_srq_from_attr) that translates user-supplied SRQ attributes into the driver’s internal SRQ object.
• The resize routine (rxe_queue_resize) that reallocates or resizes the underlying ring/buffer for the SRQ receive queue.
• The SRQ validation routine (rxe_srq_chk_attr or equivalent) that reads srq->rq.queue->buf->index_mask to validate or report max_wr values and other attributes.

When an initial ibv_modify_srq triggers rxe_queue_resize and that resize fails, rxe_srq_from_attr may clear or leave srq->rq.queue as NULL. If the same user or client then calls ibv_modify_srq again (the same or a different modifying path that reuses rxe_srq_from_attr), rxe_srq_chk_attr can dereference srq->rq.queue without re-checking for NULL and attempt to read queue‑specific fields such as buf->index_mask. That unconditional access to a NULL pointer produces a kernel oops. This sequence is the core of the vulnerability as recorded in the public advisories.

Observable symptom and call trace (paraphrased)​

Field reports and the advisory descriptions show a reproducible kernel oops stack that points into rxe_modify_srq / rxe_srq_chk_attr and up through the ib_uverbs invocation path. In practice the vulnerable sequence is triggered by two consecutive modify requests under a specific error condition where the first resize fails. The net effect is a host‑level crash (availability impact) rather than an immediate privilege escalation or data disclosure. Public trackers list the same call‑path pattern in their descriptions.

---

Verified facts and timeline​

• The vulnerability record was published and widely indexed on December 24, 2025 (published timestamps in public trackers and OSV).
• Upstream kernel maintainers accepted a small, surgical correction to the rxe code that prevents the NULL dereference by ensuring the SRQ queue pointer is not left observable as NULL to validation paths, and/or by adding defensive checks in the validation path. The fix is present in the upstream stable commit stream referenced by vulnerability aggregators.
• Multiple independent vulnerability databases (OSV, SUSE, cvefeed, OpenCVE and vendor trackers) have recorded CVE‑2025‑68379 and map it to the upstream fix, confirming the technical facts across separate sources.

Where public patch diffs are available they show a conservative code change pattern typical of kernel correctness fixes: add a NULL check or ensure correct lifecycle restoration after a failed resize, rather than rewriting large driver subsystems.

---

Impact assessment​

Primary impact: availability​

• The vulnerability’s primary impact is availability: a kernel NULL pointer dereference resulting in an oops or panic. That means hosts running vulnerable kernels with the rxe driver (soft‑RoCE) can crash or become unstable if the sequence is exercised. Multiple advisories and trackers classify the effect as an availability/stability risk.

Exploitability​

• The attack vector is local or tenant‑adjacent because attackers must be able to invoke ibverbs/ib_uverbs operations or otherwise cause SRQ resize/modify flows. Typical vectors include unprivileged or containerized workloads that can access RDMA verbs, guest tenants in misconfigured virtualization setups, or local processes that have RDMA access. There is no authoritative public proof‑of‑concept demonstrating remote, unauthenticated remote exploitation that yields code execution. Public EPSS and CVSS assignments were sparse or absent at initial publication. Treat claims of immediate RCE as unverified unless a reproducible exploit is published.

Who should care​

• High priority: systems that enable RDMA or soft‑RoCE (rxe), testbeds that expose ibverbs directly, Linux VMs or containers in multi‑tenant hosts where untrusted guests can call uverbs, and developer appliances that rely on rxe for RDMA emulation.
• Medium priority: workstations or build hosts that include rxe modules but do not expose verbs to untrusted code.
• Low priority: systems without RDMA support, or where rxe is neither built nor loaded. Use lsmod and kernel config when triaging.

---

Detection and triage: what to hunt for​

Operational detection is straightforward because the failure produces kernel oops traces and explicit NULL dereference signatures.

• Search kernel logs (journalctl -k / dmesg) for frames mentioning rxe, rxe_modify_srq, rxe_srq_chk_attr, ib_uverbs and "NULL pointer dereference", "oops", or "BUG". Those traces are the primary artifact of the issue.
• Short triage commands:
• lsmod | grep -i rxe
• dmesg | egrep -i 'rxe|ib_uverbs|rxe_modify_srq|NULL pointer dereference|oops'
• uname -r and check your distro’s kernel changelog for CVE‑2025‑68379 or the upstream commit IDs.

If you capture an oops, preserve vmcore/dmesg before rebooting — the call stack is the main forensic evidence. Public advisories reproduce the typical stack pattern for the crash, which helps validate detection hits.

---

Remediation and mitigation: prioritized checklist​

• Apply vendor or upstream kernel updates that include the rxe patch.
• The definitive remediation is to run a kernel that incorporates the upstream stable commit or a distro backport and then reboot into that kernel. Verify the packaged changelog or vendor advisory explicitly lists CVE‑2025‑68379 or the upstream commit ID before declaring a host remediated.
• If immediate patching is impossible:
• Unload or blacklist the rxe module on hosts that do not require soft‑RoCE (echo "blacklist rxe" > /etc/modprobe.d/blacklist-rxe.conf and rmmod rxe). Note: unloading may impact software that relies on rxe; evaluate impact before doing this.
• Restrict access to RDMA and ibverbs interfaces using host hardening (capabilities, cgroup/node isolation, container seccomp profiles, or by limiting which users can access /dev/infiniband and uverbs interfaces).
• Isolate RDMA hosts from untrusted tenants; avoid exposing uverbs to multi‑tenant workloads until patched.
• For appliances, VMs and vendor images (including WSL and Azure images):
• Don’t assume a given vendor image is patched because upstream contains a fix. Confirm vendor‑level attestations, package changelogs and image manifests for the fix. Vendor attestation practices vary — Microsoft’s machine‑readable VEX/CSAF attestations are useful for Azure Linux SKUs, but other artifacts must be verified individually.
• Validation after patch:
• Reboot into the patched kernel, exercise SRQ create/resize/modify paths in a test environment (controlled ibv_modify_srq sequences), and monitor kernel logs for at least one maintenance window to ensure the crash does not reappear.

---

Practical rollout and testing guidance​

• Stage the rollout: pilot → staging → production. Because this is a kernel update, coordinated reboots and failover plans are required for production RDMA clusters.
• Test harness: run your existing RDMA unit tests (or the rdma-core test suite) against representative hosts. Specifically exercise ibv_modify_srq success and failure paths, and retry sequences that previously produced the crash.
• For cloud images and appliances: obtain vendor confirmation that published images include the backport, or rebuild images from a verified patched kernel. Public advisories stress that vendor images can lag upstream changes and must be validated per artifact.

---

Why the upstream fix is low‑risk — and where residual risks remain​

Strengths of the fix​

• The patch is small and defensive: it eliminates the NULL observation window or adds a guard in the validation path rather than reworking rxe semantics. That pattern makes the change straightforward to backport into stable kernel series and reduces the risk of regressions.
• Upstream and distribution trackers confirm the same technical fix across independent sources — a strong signal that the change is targeted and correct.

Residual risks and caveats​

• Vendor backport lag: embedded appliances, vendor‑supplied images and some cloud marketplace images can remain vulnerable until vendors ship updated kernels. Inventory and validate each image artifact individually; an upstream fix does not automatically mean every downstream image is fixed.
• Attack surface remains local/tenant‑adjacent. In multi‑tenant cloud operators, that means attacker proximity could be as little as a co‑tenant VM that has RDMA access — a configuration more common in high‑performance networking environments.
• The fix addresses a specific lifecycle/race failure. Lifecycle mistakes are common building blocks for more complex exploit chains; while there is no known public exploit chaining this defect into RCE, defenders should remain cautious and keep systems patched.

---

Recommended detection rules and SOC playbook​

• Alert on kernel oopses whose stack traces include rxe symbols or ib_uverbs handlers. Example keywords: "rxe", "rxe_modify_srq", "rxe_srq_chk_attr", "ib_uverbs", "NULL pointer dereference", "oops".
• Triage flow:
• Capture vmcore / kernel dump immediately.
• Correlate with recent uverbs or RDMA operation calls (audit, process lists, container activity).
• Identify the calling process and container/VM to determine whether this was an accidental misconfiguration or potentially intentional misuse.
• Patch the host and schedule a reboot; validate remediation per the vendor/distro advisory.
• For blue/green cloud or orchestrated clusters, migrate workloads off suspect hosts, patch images, and redeploy to avoid unplanned downtime from kernel oops.

---

Microsoft/MSRC note and mixed‑estate guidance​

The user’s original attempt to view a Microsoft MSRC CVE page returned a "page not found" or unavailable result; that is an expected symptom of some MSRC pages that are dynamically rendered or not directly fetchable by automated scrapers. Do not treat a missing MSRC page as evidence the CVE is irrelevant to Microsoft images. Microsoft’s VEX/CSAF attestations for specific products (for example, Azure Linux) are authoritative for those SKUs, but they cover only the artifacts Microsoft has explicitly mapped — not every Microsoft‑branded image or WSL kernel by default. Operators should validate WSL kernels, Azure Marketplace SKUs and vendor images individually for the fixed kernel version rather than assuming a single product-level attestation implies global safety.

---

Critical analysis and final recommendations​

CVE‑2025‑68379 is a representative example of how small lifecycle mistakes in kernel device drivers can produce outsized operational consequences. The vulnerability does not change RDMA semantics or device protocols; it simply allows an error path to leave driver state inconsistent and observable, which is a classic correctness bug. The upstream fix is appropriate: surgical, low‑risk, and easy to audit. Because the remediation path is a kernel update, the operational burden is non‑trivial — patch windows, reboots, validation and vendor coordination are required.
Administrators and platform engineers should prioritize as follows:

• Immediate: inventory hosts that load the rxe driver or expose RDMA verbs; search kernel logs for the crash signature.
• Near term: apply vendor kernel updates and backports in a staged manner and reboot hosts into patched kernels. Verify the changelog or vendor advisory explicitly references the CVE or upstream commit ID before treating systems as remediated.
• Short term mitigations: where patching cannot be performed safely or quickly, consider unloading rxe or locking down who can access ibverbs/uverbs interfaces; isolate RDMA hosts from untrusted tenants.
• Long term: incorporate kernel module and CVE tracking into baseline image pipelines and vendor image validation, so the long tail of appliances and marketplace images does not remain exposed.

The technical fix and vendor responses show the open‑source and distribution ecosystem responding quickly with a low‑risk remediation. The operational work for defenders is classic systems management: inventory, coordinate maintenance, deploy, validate and monitor. Treat availability‑first kernel defects seriously — a single host kernel oops in a clustered RDMA environment can cascade into wide‑scale application outages.

---

Conclusion
CVE‑2025‑68379 is a targeted yet consequential kernel robustness bug in the RDMA soft‑RoCE (rxe) code that permits a NULL dereference after a failed SRQ resize when modify operations are retried. The patch is simple and non‑invasive, and upstream and downstream trackers have captured the fix and are shipping backports. The recommended course of action is unambiguous: inventory RDMA‑enabled systems, verify vendor package mappings for the CVE, apply patched kernels, reboot, and monitor kernel logs. For mixed Windows–Linux estates, verify each Linux artifact (Azure images, WSL kernels, marketplace images) individually rather than assuming a single vendor attestation covers all artifacts. Staying current with vendor kernel updates and retaining good kernel‑level telemetry are the practical, effective defenses against this class of availability vulnerabilities.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center