CVE-2026-46297

What it actually does

This Linux kernel flaw affects the libwx network driver interrupt registration path. The driver incorrectly uses request_threaded_irq() with a primary interrupt handler, no threaded handler, and the IRQF_ONESHOT flag. Newer generic IRQ code warns on that invalid combination, producing a kernel WARNING from __setup_irq(). On systems configured to panic on kernel warnings, this can escalate from a warning into a local denial of service through a kernel panic during driver or virtual function interrupt initialization.

Why it matters to the business

Systems using affected Linux kernel versions with libwx-supported network hardware or virtual functions may experience service disruption if the driver initialization path triggers a kernel warning and the system is configured to treat warnings as fatal. The issue is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so broad internet-scale exploitation is unlikely; however, production network hosts with strict panic-on-warning settings could suffer unexpected outages during boot, driver reload, or network device reconfiguration.

How an attack unfolds

An attacker would need a way to cause the affected libwx driver path to register the VF miscellaneous interrupt. In practical terms, that usually requires local access, administrative control over network device configuration, or the ability to trigger driver load, reload, reset, or virtual-function setup on a system with affected hardware. When the vulnerable code calls request_threaded_irq() with IRQF_ONESHOT but without a threaded handler, the kernel generic IRQ subsystem emits a warning at __setup_irq(). If the system has panic_on_warn enabled, that warning can terminate the kernel and cause a denial of service. Without panic-on-warning behavior, the result is typically a logged kernel warning rather than a full compromise.

How to fix it

Upgrade to a Linux kernel build that includes the fix changing the libwx VF miscellaneous interrupt registration from request_threaded_irq() with IRQF_ONESHOT to request_irq() without IRQF_ONESHOT. If vendor fixed package versions are not available, obtain the corrected kernel from the Linux distribution or appliance vendor once published. As temporary mitigations, avoid unnecessary reloads or reconfiguration of affected libwx network devices, restrict administrative access to network driver and SR-IOV configuration, and review whether panic_on_warn is required on production systems where availability is critical. Do not disable kernel safety settings without evaluating operational and security tradeoffs.

How to confirm the fix worked

Confirm that the running kernel includes the upstream or vendor patch for the libwx interrupt registration change. Validate using the active running kernel, not only the installed package list, because a reboot may be required after kernel updates. Check kernel logs during boot, driver load, VF creation, and network device reset for absence of the IRQF_ONESHOT warning from __setup_irq(). Where feasible, test driver initialization in a maintenance window and verify that no kernel WARNING or panic occurs. Also verify the panic_on_warn setting so teams understand whether a warning would become an outage.

Typical attack path

1. Identify a Linux system running an affected kernel with libwx-supported network hardware or configured virtual functions.
2. Obtain local privileges or administrative access sufficient to manipulate driver loading, network device reset, SR-IOV/VF setup, or related hardware configuration.
3. Trigger the libwx VF miscellaneous interrupt setup path, such as through driver initialization, reload, or device reconfiguration.
4. Cause the invalid IRQ registration combination to reach the kernel IRQ setup code.
5. If panic_on_warn is enabled, force a kernel panic and service outage; otherwise, generate kernel warning logs without direct code execution.

How to detect it

Review kernel ring buffer, system journal, syslog, and crash dump records for evidence that the affected interrupt setup path was triggered. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore records, and hardware or virtualization management logs showing driver reloads, SR-IOV changes, VF creation, or network device resets. Look for kernel WARNING entries referencing kernel/irq/manage.c, __setup_irq(), IRQF_ONESHOT, request_threaded_irq(), and libwx or Wangxun network driver activity. If systems rebooted unexpectedly, correlate prior kernel warning messages with panic_on_warn settings and crash dump timestamps. There are no known public threat actors or exploitation campaigns associated with this issue, so detection should focus on stability events and local administrative activity rather than remote intrusion indicators.

• WARNING: kernel/irq/manage.c:1502
• __setup_irq+0x4fa/0x760
• IRQF_ONESHOT without a threaded handler
• request_threaded_irq
• IRQF_ONESHOT
• libwx
• panic_on_warn
• kernel panic - not syncing
• /proc/sys/kernel/panic_on_warn
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Prioritize patching on Linux systems using libwx-supported network adapters, SR-IOV, or virtual-function configurations, especially where uptime is critical.
• Inventory kernels and network hardware drivers to determine whether libwx is present and loaded.
• Review /proc/sys/kernel/panic_on_warn and related hardening settings to understand outage risk if this warning is triggered.
• Monitor kernel logs for IRQF_ONESHOT, __setup_irq(), request_threaded_irq(), and libwx-related warning messages.
• Restrict access to privileged operations that can reload drivers, reset network devices, or change SR-IOV/VF configuration.
• Because this is not KEV, not ransomware-associated, and has very low EPSS, handle through normal kernel maintenance unless affected systems have high availability requirements or panic-on-warning is enabled.