Linux Kernel EUVD-2026-38851

Requires the target to be running the Linux airoha_eth driver - i.e., an Airoha/MediaTek SoC with the QDMA Ethernet hardware - on a vulnerable kernel; the bug only manifests when traffic is distributed such that skb queue_mapping selects netdev TX queues beyond the AIROHA_NUM_TX_RING hardware rings, creating the enqueue/completion BQL accounting mismatch. Limiting factors: the defect is confined to this specific SoC driver (no impact on other NICs or general-purpose servers), it produces availability degradation only (C:N/I:N), and the trigger is tied to normal queue-mapping/completion behavior on the device rather than a clearly remote attacker-controlled input - the input's AV:N rating is not well supported by the description and should be verified with the vendor.

Signals conflict and should be read with caution. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5) rates this as a remote, unauthenticated, high-availability-impact issue, but the description describes a BQL accounting imbalance in a niche SoC TX path that is far more consistent with a local/on-device reliability defect than a remotely weaponizable DoS - the AV:N rating is likely overstated. EPSS is very low (0.17%, 7th percentile) and is NOT in CISA KEV, with no public exploit identified, all of which align with low real-world exploitation risk. There is also a tagging conflict: the input tags this 'Information Disclosure,' yet the CVSS vector sets C:N/I:N and only A:H, so the confidentiality framing is unsupported by the description - treat the 'Information Disclosure' tag as erroneous. Net: this is a legitimate stability bug worth patching during routine kernel maintenance for affected Airoha hardware, not an urgent security emergency despite the 7.5 score.

On a device using the Airoha Ethernet driver, sustained or specifically patterned TX traffic causes BQL in-flight counters to drift out of sync between the enqueue and completion paths, eventually stalling one or more transmit queues and degrading or halting outbound networking until the interface is reset. No public exploit code exists, and given AC and the on-device nature of the trigger, this is more likely to manifest as a reliability failure than a deliberately driven attack.