CVE-2026-43128

What it actually does

This is a local Linux kernel memory-corruption flaw in the RDMA user-memory dma-buf handling path. When ib_umem_dmabuf_map_pages() fails inside ib_umem_dmabuf_get_pinned_with_dma_device(), the dma-buf can be unpinned immediately while the internal pinned state remains set. Later cleanup through ib_umem_release() and ib_umem_dmabuf_revoke() can call dma_buf_unpin() a second time, creating an incorrect unmap/unpin sequence. Depending on kernel configuration, RDMA hardware, dma-buf usage, and allocator state, this can lead to kernel memory corruption, kernel crash, or potential local privilege escalation.

Why it matters to the business

A local attacker who already has the ability to run code and access the affected RDMA/dma-buf interfaces could crash Linux systems or potentially gain elevated privileges. The highest operational risk is on servers using RDMA-capable hardware, GPU/direct-memory-sharing workloads, high-performance computing, storage fabrics, virtualization, or containerized workloads where device access is exposed. The CVSS score is high, but current exploitation signals are low: EPSS is 0.00139 with no 30-day increase, it is not listed in CISA KEV, and no exploit maturity is reported. Systems that do not expose RDMA or dma-buf paths to untrusted local users have materially lower practical risk.

How an attack unfolds

An attacker first needs local code execution on a Linux system and access to the relevant RDMA user verbs or dma-buf registration path. They then create or obtain a dma-buf-backed memory object and attempt to register it through the RDMA memory-registration interface in a way that causes ib_umem_dmabuf_map_pages() to fail, for example by provoking an error in page mapping or reservation waiting. In the vulnerable kernel path, the failure handling unpins the dma-buf but leaves the object marked as pinned. When the UMEM object is later released, the normal revoke/release path treats the object as still pinned and calls dma_buf_unpin() again. That double unpin can corrupt kernel memory-management state. A reliable exploit would need to shape kernel heap state and timing to convert this corruption into privilege escalation; less controlled attempts are more likely to cause a kernel oops, panic, RDMA subsystem failure, or denial of service.

How to fix it

Apply a Linux kernel update from the distribution, appliance, cloud image, or hardware vendor that includes the upstream fix for 'RDMA/umem: Fix double dma_buf_unpin in failure path'. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor kernel advisories and changelogs for CVE-2026-43128 or the named RDMA/umem patch. Reboot systems after installing the fixed kernel unless a vendor-supported live patch explicitly covers this code path. Where immediate patching is not possible, reduce exposure by disabling unused RDMA functionality, unloading or blacklisting unneeded RDMA-related modules where operationally safe, restricting access to /dev/infiniband/* device nodes, limiting membership in groups that can use RDMA devices, avoiding passthrough of RDMA devices into untrusted containers or virtual machines, and enforcing least-privilege device access through cgroups, udev rules, container runtime policy, or hypervisor policy.

How to confirm the fix worked

Confirm the running kernel version is a vendor-fixed build, not merely that an updated package is installed. Validate with the distribution's security advisory, kernel changelog, or package metadata showing the RDMA/umem dma-buf double-unpin fix. After reboot, verify the active kernel with uname -a or equivalent inventory tooling. Confirm whether RDMA is present and exposed by checking loaded RDMA modules, RDMA devices, and user-accessible /dev/infiniband/* nodes. If mitigations are used, verify untrusted users and workloads cannot open RDMA user verbs devices or access passed-through RDMA hardware. For high-assurance environments, test a representative patched host with RDMA workloads to ensure normal memory registration and dma-buf operations continue without kernel warnings, oopses, or driver regressions.

Typical attack path

1. Gain local code execution on a Linux system, such as through a shell, compromised user account, container escape prerequisite, or workload execution context.
2. Confirm access to RDMA user interfaces or device nodes associated with RDMA/dma-buf memory registration, such as user verbs devices.
3. Create or reference a dma-buf-backed memory object suitable for RDMA UMEM registration.
4. Trigger the RDMA dma-buf UMEM registration path and induce a failure in ib_umem_dmabuf_map_pages().
5. Rely on the vulnerable failure path to unpin the dma-buf while leaving the internal pinned flag set.
6. Force object cleanup through the UMEM release/revoke path, causing a second dma_buf_unpin() call.
7. Attempt to turn the resulting kernel memory corruption into privilege escalation, or cause a kernel crash/denial of service if exploitation is not reliable.

How to detect it

There are no public, CVE-specific exploitation indicators provided, and successful exploitation may leave few artifacts beyond normal local activity and kernel instability. Detection should focus on host telemetry and kernel logs from RDMA-enabled systems. Review journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, audit logs, EDR telemetry, and device-access logs for signs of RDMA user verbs activity followed by kernel warnings, oopses, panics, KASAN reports, refcount anomalies, or dma-buf/RDMA cleanup errors. Investigate local processes that accessed /dev/infiniband/uverbs* shortly before a crash or kernel warning, especially if run by non-administrative users, container workloads, batch jobs, or recently created accounts. Look for repeated crashes involving ib_core, ib_umem, dma_buf, mlx5_ib, rxe, rdma_ucm, or related modules. Correlate suspicious events with privilege changes, new setuid binaries, unexpected kernel module loading, abnormal container device access, or post-crash persistence attempts. Because this is a kernel memory-corruption issue, absence of logs does not prove absence of exploitation; memory forensics or crash-dump analysis may be required after suspicious failures.

• ib_umem_dmabuf_get_pinned_with_dma_device
• ib_umem_dmabuf_map_pages
• ib_umem_dmabuf_revoke
• ib_umem_release
• dma_buf_unpin
• /dev/infiniband/uverbs
• /dev/infiniband/rdma_cm
• KASAN: use-after-free
• KASAN: slab-use-after-free
• general protection fault
• kernel BUG
• Oops:
• BUG: unable to handle kernel NULL pointer dereference
• WARNING: CPU:
• refcount_t: underflow
• kernel panic
• ib_core
• mlx5_ib
• rdma_ucm
• dma_resv_wait_timeout

What your security team should do

• Prioritize patching Linux systems that expose RDMA, InfiniBand, RoCE, or dma-buf-backed direct-memory workflows to non-administrative users or untrusted workloads.
• Inventory systems with RDMA-capable hardware, loaded RDMA kernel modules, or accessible /dev/infiniband/* device nodes.
• Restrict RDMA device-node access to trusted users and workloads until fixed kernels are deployed.
• Do not pass RDMA devices into untrusted containers or virtual machines unless the host kernel is confirmed fixed and device access is required.
• Monitor kernel logs for oops, panic, KASAN, use-after-free, refcount, or dma-buf/RDMA warnings that coincide with RDMA memory-registration activity.
• Treat suspicious local privilege changes or crashes on RDMA-enabled systems as higher priority even though EPSS is currently low and there is no KEV listing.
• Track vendor advisories for exact fixed kernel versions because no fixed versions were provided in the source data.