EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
- •No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: —CVSS v2: —Exploit: None knownExposed services: Not assessed
No fix is confirmed yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for the fix.
The CVE record's CNA (kernel.org) lists Linux versions before 2.6.33 and 7.4-rc1 and later as unaffected. No release containing a fix is confirmed on record.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_teql: fix use-after-free on lower qdisc drop
The issue: teql_master_xmit() tests the slave's ndo_start_xmit() return
value against NETDEV_TX_OK alone. A slave that consumes the skb but
returns an error code (rc < NET_XMIT_MASK, e.g. NET_XMIT_DROP) is treated
as if the skb were still owned, so the loop restores skb->dev and calls
__skb_pull() on it. A VLAN slave returns the result of dev_queue_xmit()
from its ndo_start_xmit() (propagated since cbbef5e18307), and when the
lower qdisc drops the packet that value is NET_XMIT_DROP after the skb
has been freed, giving a use-after-free in teql_master_xmit().
The Fix: test for consumption with dev_xmit_complete(), which accepts
NETDEV_TX_OK and every rc < NET_XMIT_MASK, matching other callers that
need to distinguish consumed results from busy. Only NETDEV_TX_OK keeps
the packet counted in tx_packets/tx_bytes and advances the slave; a
consumed result that is neither a success nor NET_XMIT_CN ends the
attempt and is charged to tx_dropped, so lower-qdisc drops are no longer
reported as good transmits. NET_XMIT_CN is counted like success because
it can accompany acceptance of the current packet: pfifo_head_drop drops
the old head, enqueues the current skb and returns NET_XMIT_CN.
Conditions to recreate the bug:
With CONFIG_NET_SCH_TEQL,
CONFIG_VLAN_8021Q and CONFIG_DUMMY enabled, add lkrdummy0 (dummy) and
lkrvlan0 (VLAN id 37 on lkrdummy0); set a pfifo limit 0 root on lkrdummy0
and a teql0 root on lkrvlan0; bring teql0 up with an address and send one
UDP packet to it. The VLAN xmit returns NET_XMIT_DROP from the lower
qdisc while holding a freed skb.
What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)
- EG Severity
- Not assessed: no CVSS publishedA missing CVSS is not a severity of zero.
- EG Likelihood
- Unknown (no EPSS on record)Unknown, not low: FIRST has published no EPSS probability for this CVE.
- Confirmed exploitation
- None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
- EG Priority
- No SSVC decision: EchelonGraph has not assessed this CVECISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.Each input and its source, and whom BOD 26-04 binds: the BOD 26-04 block below.
BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.
No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.
The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it