CVE-2026-22981
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-23

Last updated on: 2026-04-02

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: idpf: detach and close netdevs while handling a reset Protect the reset path from callbacks by setting the netdevs to detached state and close any netdevs in UP state until the reset handling has completed. During a reset, the driver will de-allocate resources for the vport, and there is no guarantee that those will recover, which is why the existing vport_ctrl_lock does not provide sufficient protection. idpf_detach_and_close() is called right before reset handling. If the reset handling succeeds, the netdevs state is recovered via call to idpf_attach_and_open(). If the reset handling fails the netdevs remain down. The detach/down calls are protected with RTNL lock to avoid racing with callbacks. On the recovery side the attach can be done without holding the RTNL lock as there are no callbacks expected at that point, due to detach/close always being done first in that flow. The previous logic restoring the netdevs state based on the IDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence the removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is still being used to restore the state of the netdevs following the reset, but has no use outside of the reset handling flow. idpf_init_hard_reset() is converted to void, since it was used as such and there is no error handling being done based on its return value. Before this change, invoking hard and soft resets simultaneously will cause the driver to lose the vport state: ip -br a <inf> UP echo 1 > /sys/class/net/ens801f0/device/reset& \ ethtool -L ens801f0 combined 8 ip -br a <inf> DOWN ip link set <inf> up ip -br a <inf> DOWN Also in case of a failure in the reset path, the netdev is left exposed to external callbacks, while vport resources are not initialized, leading to a crash on subsequent ifup/down: [408471.398966] idpf 0000:83:00.0: HW reset detected [408471.411744] idpf 0000:83:00.0: Device HW Reset initiated [408472.277901] idpf 0000:83:00.0: The driver was unable to contact the device's firmware. Check that the FW is running. Driver state= 0x2 [408508.125551] BUG: kernel NULL pointer dereference, address: 0000000000000078 [408508.126112] #PF: supervisor read access in kernel mode [408508.126687] #PF: error_code(0x0000) - not-present page [408508.127256] PGD 2aae2f067 P4D 0 [408508.127824] Oops: Oops: 0000 [#1] SMP NOPTI ... [408508.130871] RIP: 0010:idpf_stop+0x39/0x70 [idpf] ... [408508.139193] Call Trace: [408508.139637] <TASK> [408508.140077] __dev_close_many+0xbb/0x260 [408508.140533] __dev_change_flags+0x1cf/0x280 [408508.140987] netif_change_flags+0x26/0x70 [408508.141434] dev_change_flags+0x3d/0xb0 [408508.141878] devinet_ioctl+0x460/0x890 [408508.142321] inet_ioctl+0x18e/0x1d0 [408508.142762] ? _copy_to_user+0x22/0x70 [408508.143207] sock_do_ioctl+0x3d/0xe0 [408508.143652] sock_ioctl+0x10e/0x330 [408508.144091] ? find_held_lock+0x2b/0x80 [408508.144537] __x64_sys_ioctl+0x96/0xe0 [408508.144979] do_syscall_64+0x79/0x3d0 [408508.145415] entry_SYSCALL_64_after_hwframe+0x76/0x7e [408508.145860] RIP: 0033:0x7f3e0bb4caff
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-23
Last Modified
2026-04-02
Generated
2026-05-27
AI Q&A
2026-01-23
EPSS Evaluated
2026-05-26
NVD
EUVD
Affected Vendors & Products
Showing 5 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.7 (inc) to 6.18.6 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's idpf driver involves improper handling of network device states during a reset. Before the fix, simultaneous hard and soft resets could cause the driver to lose the virtual port (vport) state, leaving network devices down and unable to recover properly. Additionally, if the reset failed, the network device remained exposed to external callbacks while its resources were uninitialized, leading to kernel crashes such as NULL pointer dereferences. The fix involves detaching and closing network devices before reset handling to protect the reset path from callbacks, ensuring proper resource deallocation and recovery or keeping devices down if recovery fails.


How can this vulnerability impact me? :

This vulnerability can cause network interfaces to become non-functional (remain down) after resets, disrupting network connectivity. In the worst case, it can lead to kernel crashes due to improper handling of device states and resources, potentially causing system instability or downtime. This can affect the reliability and availability of systems relying on the affected network driver.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing the network interface states and kernel logs for signs of reset failures and crashes related to the idpf driver. You can use commands such as 'ip -br a' to check if interfaces unexpectedly go down after resets, and monitor kernel logs (e.g., using 'dmesg' or 'journalctl -k') for messages indicating hardware resets, firmware contact failures, or kernel NULL pointer dereferences related to idpf. For example, commands: 1) ip -br a 2) echo 1 > /sys/class/net/<interface>/device/reset 3) ethtool -L <interface> combined 8 4) dmesg | grep idpf


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves ensuring that the idpf driver is updated to the fixed version that properly detaches and closes netdevs during reset handling to prevent crashes and state loss. Avoid performing simultaneous hard and soft resets on the affected interfaces until the fix is applied. Monitor and manage network interfaces carefully to prevent exposure to external callbacks during reset failures.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart