CVE-2026-22981
ŚrednieCVSS 5.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 3 - wyżej niż 3% wszystkich znanych CVE
Streszczenie
W jądrze Linux w sterowniku idpf naprawiono błąd związany z obsługą resetu. Podczas resetu sprzętowego lub programowego sterownik zwalniał zasoby vport, ale interfejsy sieciowe (netdev) pozostawały aktywne i narażone na wywołania zwrotne, co mogło prowadzić do utraty stanu vport lub awarii jądra (NULL pointer dereference) przy kolejnym ifup/down.
Ocena ryzyka
Organizacje korzystające z kart sieciowych obsługiwanych przez sterownik idpf mogą doświadczyć awarii jądra (kernel crash) lub utraty łączności sieciowej podczas jednoczesnego resetu sprzętowego i programowego. Może to prowadzić do niedostępności usług i wymagać restartu systemu.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-22981. Jeśli aktualizacja nie jest możliwa, unikaj jednoczesnego wywoływania resetów sprzętowych i programowych na interfejsach idpf.
Inne podatności w Linux kernel idpf driver
Zobacz wszystkie- CVE-2026-22985Średnie
W jądrze Linux w sterowniku idpf występuje błąd, który powoduje zerwanie wskaźnika NULL (NULL pointer dereference) podczas wczesnych operacji ethtool, takich jak włączanie/wyłączanie rxhash, wykonywanych przed pierwszym podniesieniem interfejsu. Przyczyną jest brak inicjalizacji tablicy RSS LUT do momentu uruchomienia interfejsu. Poprawka przenosi inicjalizację LUT do momentu tworzenia vportu, dzięki czemu jest ona zawsze dostępna.
- CVE-2025-38392Średnie
W jądrze Linux w sterowniku idpf występuje błąd polegający na użyciu muteksu (cq_lock) w kontekście, w którym nie wolno usypiać (z wyłączonym przerwaniem BH). Prowadzi to do ostrzeżenia „BUG: sleeping function called from invalid context” podczas ładowania modułu, gdy włączona jest funkcja VIRTCHNL2_CAP_MACFILTER. Poprawka zamienia muteks na spinlock i zapewnia ciągłą pamięć fizyczną dla mapowania DMA.
Oryginalny opis (angielski, źródło NVD)
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
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

