CVE-2026-22981

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