CVE-2026-43147

What it actually does

This is a Linux kernel denial-of-service flaw in PCI SR-IOV handling. A locking change introduced recursive acquisition of pci_rescan_remove_lock when SR-IOV virtual functions are disabled during PCI device removal. On affected kernels, a local actor or process with permission to modify PCI sysfs attributes can trigger a kernel deadlock by enabling SR-IOV VFs on a physical function and then removing that PCI device. The result is a stuck kernel task and potential loss of availability for the affected device, driver, or host workload. The issue is availability-only: it does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Systems using SR-IOV-capable PCI devices, such as high-performance network adapters, storage controllers, or virtualization hosts, may experience device removal failures, hung kernel tasks, degraded networking, or host instability. In operational terms, a user or workload with sufficient local permissions could disrupt network or I/O availability on affected Linux systems. The CVSS score is moderate and EPSS is very low and stable, and it is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, the impact can be significant on virtualization, NFV, HPC, and cloud infrastructure where SR-IOV devices are operationally critical.

How an attack unfolds

An attacker first obtains local access to an affected Linux system and sufficient permission to write to PCI sysfs controls, typically requiring root, CAP_SYS_ADMIN-equivalent capability, or a privileged management context. The attacker identifies an SR-IOV-capable PCI physical function exposed under /sys/bus/pci/devices/ and writes a nonzero value to its sriov_numvfs file to create virtual functions. The attacker then writes to the device's remove file to trigger PCI device removal. During removal, the kernel calls into SR-IOV disable logic while already holding pci_rescan_remove_lock, attempts to acquire the same lock again, and deadlocks. The visible effect is a hung task, device removal that never completes, possible loss of the associated PCI device, and operational disruption until recovery actions such as service restart, driver reload, or host reboot are performed.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the corrected PCI/SR-IOV locking behavior. No fixed package versions were provided in the input, so track vendor advisories for the exact kernel build that supersedes the affected code. Where immediate patching is not possible, reduce exposure by limiting write access to /sys/bus/pci/devices/*/sriov_numvfs and /sys/bus/pci/devices/*/remove, disabling unnecessary SR-IOV functionality, preventing untrusted users or containers from receiving privileged access to host PCI sysfs, and restricting hardware-management automation to trusted operators. On critical virtualization or network hosts, schedule maintenance for kernel upgrades because remediation usually requires rebooting into the fixed kernel.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that includes the fix or does not contain the offending PCI/IOV locking change. Inventory exposure by checking for SR-IOV-capable devices with files such as /sys/bus/pci/devices/*/sriov_totalvfs and /sys/bus/pci/devices/*/sriov_numvfs. Validate permissions on PCI sysfs paths to ensure only trusted privileged users and services can write to sriov_numvfs and remove. After patching, confirm the active kernel version with uname -r and package-manager metadata, then verify that dmesg and journal logs do not show hung tasks, lockdep recursive-lock warnings, or call traces involving pci_rescan_remove_lock, sriov_disable, and pci_stop_and_remove_bus_device_locked. If functional testing is required, reproduce only in a non-production lab with SR-IOV hardware by enabling VFs and removing the PCI device, then confirming the operation does not deadlock.

Typical attack path

1. Gain local shell, container escape path, administrative automation access, or another execution context on an affected Linux host.
2. Obtain privileges sufficient to write to PCI sysfs device controls, such as root or a privileged hardware-management role.
3. Identify an SR-IOV-capable PCI physical function by checking /sys/bus/pci/devices/*/sriov_totalvfs and /sys/bus/pci/devices/*/sriov_numvfs.
4. Enable one or more virtual functions by writing a value to /sys/bus/pci/devices/<pci-device>/sriov_numvfs.
5. Trigger removal of the PCI physical function by writing 1 to /sys/bus/pci/devices/<pci-device>/remove.
6. Cause recursive locking in the PCI/SR-IOV removal path, leading to a kernel deadlock or hung task.
7. Leverage the resulting device or host instability to disrupt workloads dependent on the affected PCI device.

How to detect it

Look for evidence of PCI sysfs writes followed by kernel hung-task or lockdep messages. Primary log sources are kernel ring buffer output, system journal, auditd syscall/file-write logs, endpoint telemetry, shell history for privileged users, and configuration-management or hardware-orchestration logs. In Linux journals, search for lockdep deadlock reports, hung task messages, and call traces containing pci_rescan_remove_lock, sriov_disable, sriov_del_vfs, pci_stop_and_remove_bus_device_locked, remove_store, or driver-specific SR-IOV disable functions such as mlx5_sriov_disable. In audit logs, look for write activity to /sys/bus/pci/devices/*/sriov_numvfs followed shortly by writes to /sys/bus/pci/devices/*/remove. Investigate any correlated device disappearance, network interface loss, VF teardown, driver removal, or host instability. Since this vulnerability produces availability symptoms rather than a persistent implant, durable IOCs are limited to log artifacts, sysfs write traces, command histories, and kernel stack traces.

• /sys/bus/pci/devices/*/sriov_numvfs
• /sys/bus/pci/devices/*/remove
• pci_rescan_remove_lock
• sriov_disable
• sriov_del_vfs
• pci_stop_and_remove_bus_device_locked
• pci_stop_and_remove_bus_device
• remove_store
• mlx5_sriov_disable
• mlx5_core
• possible circular locking dependency detected
• trying to acquire lock
• but task is already holding lock
• INFO: task
• blocked for more than
• echo 1 > /sys/bus/pci/devices/
• echo * > /sys/bus/pci/devices/*/sriov_numvfs

What your security team should do

• Prioritize patching Linux hosts that use SR-IOV-capable network, storage, accelerator, or virtualization hardware, especially systems hosting tenant workloads or critical network functions.
• Because no fixed versions were supplied, subscribe to Linux distribution and hardware appliance advisories and map the fix to the exact kernel packages used in production.
• Restrict root-equivalent access, CAP_SYS_ADMIN, privileged containers, and hostPath-style access to /sys on systems with SR-IOV devices.
• Audit automation, orchestration, and hardware lifecycle tooling that writes to /sys/bus/pci/devices/*/sriov_numvfs or /sys/bus/pci/devices/*/remove.
• Monitor kernel logs for hung tasks and lockdep reports involving pci_rescan_remove_lock and SR-IOV disable paths.
• Treat exploitation likelihood as currently low due to low EPSS, no known public exploit maturity, and no KEV listing, but do not defer remediation on hosts where a single SR-IOV outage would be high impact.
• Prepare operational recovery procedures for affected hosts, including safe workload evacuation, driver reloads where feasible, and reboot plans if a deadlock occurs.