<Vulnerability name="CVE-2026-31691">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Moderate</ThreatSeverity>
    <PublicDate>2026-04-27T00:00:00</PublicDate>
    <Bugzilla id="2463267" url="https://bugzilla.redhat.com/show_bug.cgi?id=2463267" xml:lang="en:us">
kernel: igb: remove napi_synchronize() in igb_down()
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>4.7</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-833</CWE>
    <Details xml:lang="en:us" source="Mitre">
In the Linux kernel, the following vulnerability has been resolved:

igb: remove napi_synchronize() in igb_down()

When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9),
the XSK buffer pool is destroyed but NAPI polling continues.
igb_clean_rx_irq_zc() repeatedly returns the full budget, preventing
napi_complete_done() from clearing NAPI_STATE_SCHED.

igb_down() calls napi_synchronize() before napi_disable() for each queue
vector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear,
which never happens. igb_down() blocks indefinitely, the TX watchdog
fires, and the TX queue remains permanently stalled.

napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE.
After a full-budget poll, __napi_poll() checks napi_disable_pending(). If
set, it forces completion and clears NAPI_STATE_SCHED, breaking the loop
that napi_synchronize() cannot.

napi_synchronize() was added in commit 41f149a285da ("igb: Fix possible
panic caused by Rx traffic arrival while interface is down").
napi_disable() provides stronger guarantees: it prevents further
scheduling and waits for any active poll to exit.
Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without a
preceding napi_synchronize() in their down paths.

Remove redundant napi_synchronize() call and reorder napi_disable()
before igb_set_queue_napi() so the queue-to-NAPI mapping is only
cleared after polling has fully stopped.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in the Linux kernel's igb network driver. When an AF_XDP zero-copy application terminates abruptly, the network driver's NAPI polling mechanism can become stuck. This prevents the igb_down() function from completing, leading to the TX queue becoming permanently stalled. This can result in a Denial of Service (DoS) condition, making the network interface unresponsive.
    </Details>
    <Statement xml:lang="en:us">
igb can hang in igb_down when an AF_XDP zero copy application terminates abruptly and the XSK buffer pool is destroyed while NAPI polling keeps running. In this state the zero copy RX poll path can keep returning a full budget which prevents napi_complete_done from clearing NAPI_STATE_SCHED. igb_down then calls napi_synchronize and waits indefinitely for NAPI_STATE_SCHED to clear which never happens. This blocks the down path, triggers the TX watchdog, and can leave the TX queue permanently stalled which is a denial of service for the affected network device. The issue is not network reachable and requires local control of the host to set up and exercise AF_XDP zero copy.
    </Statement>
    <Mitigation xml:lang="en:us">
To mitigate this issue, prevent module igb from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
    </Mitigation>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:10">
        <ProductName>Red Hat Enterprise Linux 10</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:6">
        <ProductName>Red Hat Enterprise Linux 6</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-31691
https://nvd.nist.gov/vuln/detail/CVE-2026-31691
https://lore.kernel.org/linux-cve-announce/2026042757-CVE-2026-31691-5c48@gregkh/T
    </References>
</Vulnerability>