CVE-2026-31691

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: remove napi_synchronize() in igb_down()<br /> <br /> When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9),<br /> the XSK buffer pool is destroyed but NAPI polling continues.<br /> igb_clean_rx_irq_zc() repeatedly returns the full budget, preventing<br /> napi_complete_done() from clearing NAPI_STATE_SCHED.<br /> <br /> igb_down() calls napi_synchronize() before napi_disable() for each queue<br /> vector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear,<br /> which never happens. igb_down() blocks indefinitely, the TX watchdog<br /> fires, and the TX queue remains permanently stalled.<br /> <br /> napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE.<br /> After a full-budget poll, __napi_poll() checks napi_disable_pending(). If<br /> set, it forces completion and clears NAPI_STATE_SCHED, breaking the loop<br /> that napi_synchronize() cannot.<br /> <br /> napi_synchronize() was added in commit 41f149a285da ("igb: Fix possible<br /> panic caused by Rx traffic arrival while interface is down").<br /> napi_disable() provides stronger guarantees: it prevents further<br /> scheduling and waits for any active poll to exit.<br /> Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without a<br /> preceding napi_synchronize() in their down paths.<br /> <br /> Remove redundant napi_synchronize() call and reorder napi_disable()<br /> before igb_set_queue_napi() so the queue-to-NAPI mapping is only<br /> cleared after polling has fully stopped.