Cloudanix VulnDB

CVE-2026-45880

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

May 27, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in some Linux systems can let a local user or program make certain hardware cleanup operations hang until the system is patched and restarted.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel PCI peer-to-peer DMA memory mapping path. In p2pmem_alloc_mmap(), a per-CPU pgmap reference is acquired after gen_pool_alloc_owner(), but if vm_insert_page() fails, the error path does not release that reference with percpu_ref_put(). The leaked reference prevents memunmap_pages() from completing when the associated PCI device is removed, causing the removal path to hang indefinitely and potentially leaving kernel resources, device teardown, or administrative operations blocked. The issue does not provide confidentiality or integrity impact based on the available description, and exploitation requires local privileges.

Why it matters to the business

An attacker or malfunctioning local workload with access to the relevant PCI P2PDMA mmap path could cause device removal or cleanup operations to hang, resulting in service disruption, degraded host manageability, and potentially delayed maintenance or recovery actions. This is most relevant for systems using PCI peer-to-peer DMA-capable devices, such as some NVMe, accelerator, or specialized PCIe configurations. The current exploitation likelihood appears low: EPSS is 0.00155, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity is reported.

How an attack unfolds

An attacker first needs local access with sufficient privileges to interact with a PCI peer-to-peer DMA memory provider through the affected kernel path. They trigger p2pmem_alloc_mmap() in a way that successfully allocates ownership from the gen_pool_alloc_owner() path and acquires the pgmap per-CPU reference, but then causes vm_insert_page() to fail. Because the vulnerable error path does not drop the pgmap reference, the reference count remains elevated. Later, when the PCI device is removed, reset, unbound from its driver, or otherwise cleaned up, memunmap_pages() waits for the pgmap reference to drain, but it never does. The result is an indefinite hang in the device removal path, creating a local availability impact rather than direct code execution or data compromise.

How to fix it

Update the Linux kernel to a vendor-provided version that includes the PCI/P2PDMA fix adding the missing percpu_ref_put() when vm_insert_page() fails in p2pmem_alloc_mmap(). Because no exact fixed package versions were provided, use the relevant distribution or kernel vendor advisory to identify the corrected kernel release for each supported platform. After installing the updated kernel, reboot into the patched kernel so the fix is active. As interim mitigation, restrict local user access to interfaces that can exercise PCI P2PDMA mmap functionality, limit untrusted workloads on systems with P2PDMA-capable PCIe devices, and avoid unnecessary PCI hot-remove, driver unbind, or device reset operations on exposed systems until patched.

How to confirm the fix worked

Confirm the running kernel is a vendor build containing the PCI/P2PDMA change that releases the pgmap per-CPU reference on vm_insert_page() failure. Validate both package installation and active runtime state, since kernel updates usually require reboot. On Linux systems, compare the running kernel from uname -r with the patched kernel package installed by the distribution, and confirm the system has booted into the fixed kernel. Where source validation is available, verify that the p2pmem_alloc_mmap() error path calls percpu_ref_put() after vm_insert_page() failure. Functional validation can include controlled testing on non-production hardware to ensure failed mmap attempts do not cause PCI device removal or driver unbind operations to hang.

Typical attack path

  1. Obtain local access to a Linux system using an affected kernel and PCI P2PDMA-capable device path.
  2. Identify or access an interface that exercises PCI P2PDMA memory mmap handling.
  3. Trigger p2pmem_alloc_mmap() so that gen_pool_alloc_owner() succeeds and the pgmap per-CPU reference is acquired.
  4. Force or induce vm_insert_page() failure during the mapping operation.
  5. Leave the leaked pgmap reference in place due to the missing percpu_ref_put() on the failure path.
  6. Trigger or wait for PCI device removal, driver unbind, hot-remove, reset, or cleanup.
  7. Cause memunmap_pages() to wait indefinitely, resulting in a local denial of service or blocked device teardown operation.

How to detect it

Review kernel logs and system journals for evidence of PCI device removal, driver unbind, hotplug, reset, or memory unmap operations hanging after failed mmap activity involving PCI peer-to-peer DMA memory. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, systemd logs for device units, and any workload logs that record mmap failures against PCIe device files. Look for blocked tasks, hung task watchdog messages, kernel stack traces referencing p2pmem_alloc_mmap(), vm_insert_page(), memunmap_pages(), percpu_ref, PCI P2PDMA, or driver unbind/removal. Because this vulnerability does not create a unique network signature and may also be triggered accidentally, detection should focus on local kernel artifacts showing failed PCI P2PDMA mmap followed by indefinite waits during device teardown. If threat hunting, correlate local user activity, container workloads, or device-management commands with kernel hangs or stalled sysfs unbind/remove operations.

  • p2pmem_alloc_mmap
  • vm_insert_page
  • memunmap_pages
  • percpu_ref_put
  • gen_pool_alloc_owner
  • PCI/P2PDMA
  • P2PDMA
  • p2pmem
  • hung task
  • blocked for more than
  • sysfs unbind
  • /sys/bus/pci/drivers/
  • /sys/bus/pci/devices/
  • driver unbind
  • device removal
  • remove_store
  • pci_stop_and_remove_bus_device

What your security team should do

  • Inventory Linux systems with PCI P2PDMA-capable hardware or workloads that interact with PCI peer-to-peer DMA mappings, prioritizing those for patching.
  • Track Linux distribution and kernel vendor advisories for CVE-2026-45880 and deploy the first fixed kernel available for each platform.
  • Reboot systems after kernel update and verify the active kernel is the patched version, not only that the package is installed.
  • Restrict local shell, container, and workload access on systems with relevant PCIe devices until remediation is complete.
  • Monitor for hung PCI device removal, driver unbind, or memunmap_pages-related kernel stalls as possible signs of attempted triggering or accidental exposure.
  • Because exploitation is local and currently not known to be weaponized, prioritize based on device exposure and multi-user or untrusted workload density rather than internet exposure.

The record

In the Linux kernel, the following vulnerability has been resolved: PCI/P2PDMA: Release per-CPU pgmap ref when vm_insert_page() fails When vm_insert_page() fails in p2pmem_alloc_mmap(), p2pmem_alloc_mmap() doesn't invoke percpu_ref_put() to free the per-CPU ref of pgmap acquired after gen_pool_alloc_owner(), and memunmap_pages() will hang forever when trying to remove the PCI device. Fix it by adding the missed percpu_ref_put().

Affected packages

Ecosystem Package Introduced Fixed