CVE-2026-22981

idpf: detach and close netdevs while handling a reset

published January 23, 2026

CVSS
—
EPSS
0%
Percentile
2.7
In the wild
Unconfirmed
What it is

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

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00135 · 2.7th percentile
Published
2026-01-23T15:24Z
EPSS history
Timeline
  • 23 JAN 15:24Z
    idpf: detach and close netdevs while handling a reset
    cvelistv5