CVE-2026-46142

What it actually does

This is a local denial-of-service flaw in the Linux kernel network driver support code for libwx-based devices. During virtual function (VF) initialization, the driver can attempt to read WX_CFG_PORT_ST, a register that is restricted to the physical function (PF). On affected systems using the impacted driver and SR-IOV/virtual-function networking, that illegal VF register access can hang the system. The CVSS profile indicates local access with low attack complexity and low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can cause an affected Linux host to hang, interrupting workloads that depend on that host and potentially causing service downtime, failover events, degraded network availability, or operational disruption in virtualized and containerized environments that use SR-IOV virtual functions. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, environments that allow untrusted or semi-trusted local users, tenants, or workloads to influence VF initialization should treat it as an availability risk.

How an attack unfolds

An attacker first needs local access with sufficient privileges to cause or influence initialization of an affected network virtual function on a vulnerable Linux kernel. In a susceptible configuration, the VF initialization path incorrectly attempts to read a PF-only hardware register, WX_CFG_PORT_ST. Because the VF is not permitted to access that register, the device reports an illegal register access condition. The kernel/driver interaction can then lead to a system hang, producing a denial of service for the host and any workloads running on it. Exploitation does not require user interaction and is focused on availability disruption rather than data theft or code execution.

How to fix it

Update the Linux kernel to a vendor release that contains the upstream fix for the libwx VF register-access bug. Because no exact fixed package versions were provided, use the latest stable kernel or distribution kernel advisory that references this fix. Where immediate patching is not possible, reduce exposure by disabling SR-IOV/VF use for affected libwx-supported network devices, preventing untrusted local users or workloads from triggering VF creation or reinitialization, restricting access to device-management interfaces, and scheduling controlled reboots only after applying a fixed kernel. Mitigations should be validated with the relevant hardware and distribution vendor because network-driver behavior can vary by kernel branch and backport status.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the upstream fix for the libwx VF illegal register access issue or a distribution backport of that change. Check the kernel version against the Linux distribution vendor’s security advisory and changelog. On systems using affected hardware, validate that VF initialization no longer produces illegal register-access errors, kernel warnings, device resets, or system hangs. Review whether SR-IOV remains enabled only where needed and whether permissions around VF lifecycle operations are limited to trusted administrators or orchestration components.

Typical attack path

1. Obtain local access to a Linux system using an affected kernel and libwx-supported network hardware configuration.
2. Identify that SR-IOV or virtual-function networking is enabled and that a VF can be initialized or reinitialized.
3. Trigger VF initialization through permitted local administrative, tenant, orchestration, or device-management actions.
4. Cause the vulnerable driver path to read the PF-restricted WX_CFG_PORT_ST register while operating as a VF.
5. Induce an illegal register access condition that results in a host hang and denial of service.

How to detect it

To determine whether this was already exploited or encountered, review host-level telemetry because this flaw manifests as an availability event rather than a conventional compromise. Examine kernel logs, persistent journal entries, crash dumps, hypervisor/orchestration logs, and hardware management telemetry around the time of unexplained hangs, watchdog resets, or reboots. Focus on systems with SR-IOV/VF networking enabled and libwx-supported devices. Look for illegal register access messages, PCI or network-driver errors, VF initialization attempts, device reset messages, kernel soft lockups/hard lockups, watchdog timeouts, and abrupt system restarts shortly after VF creation or reconfiguration. If named threat actors or public exploit activity later emerge, correlate local-user activity and administrative actions that created, bound, unbound, or reinitialized VFs immediately before the failure. Absence of logs may occur if the host hangs before messages are flushed, so include out-of-band management logs, serial console logs, pstore/ramoops, kdump/vmcore analysis, and virtualization platform events where available.

• WX_CFG_PORT_ST
• illegal register access
• libwx
• VF illegal register access
• Virtual Function
• SR-IOV
• sriov_numvfs
• soft lockup
• hard lockup
• watchdog: BUG: soft lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• kernel: watchdog
• PCI_FUNC
• pdev->devfn

What your security team should do

• Inventory Linux hosts using SR-IOV or virtual-function networking with libwx-supported network devices and prioritize those running multi-tenant, production, or high-availability workloads.
• Patch affected hosts to a kernel version containing the libwx VF register-access fix, following distribution vendor guidance.
• If patching is delayed, temporarily disable SR-IOV/VFs on affected devices or restrict VF lifecycle operations to trusted administrators and automation only.
• Monitor kernel logs for illegal register access, libwx driver errors, VF initialization failures, PCI device resets, and unexplained host hangs or watchdog events.
• Because EPSS is very low and there is no KEV or known ransomware use, prioritize remediation based on local exposure and business criticality rather than emergency internet-facing exploitation risk.
• After remediation, perform controlled VF initialization testing during a maintenance window to confirm the host remains stable.