Independent & educational platform Not a government body. No link or affiliation with any government organisation. Made for learning only. Test only systems you own or are authorised to test. Become a Partner or Sponsor → Full disclaimer

CVE-2026-90083

Severity not reported
Data quality: partial. Some fields were not provided by the source.

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: Only operate on Ethernet frames act_ife encapsulates/decapsulates the…

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: Only operate on Ethernet frames act_ife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hard_header_len as the length of that header. That is only correct for Ethernet devices: on a device where hard_header_len does not match the L2 header that was actually pulled (PPP reports PPP_HDRLEN while nothing is stripped on ingress), the ingress skb_push()/skb_pull() use the wrong length and can hit skb_under_panic when headroom is tight. IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so instead of trying to make the offsets work for arbitrary link types, simply drop packets that do not carry an Ethernet header. Checking skb->dev->type alone is not enough. We have to cater for a corner case where mirred can redirect an skb from a non-Ethernet device to an Ethernet one, and skb->dev then says nothing about the framing the skb actually has: an skb redirected from ppp0 reaches the target's ingress hook with mac_len 0 and no Ethernet header at all. So at ingress also require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so the device type is all we have; a bogus redirect there yields a malformed frame rather than an out-of-bounds push, and it would be malformed with or without IFE. That corner case is not theoretical - redirecting from ppp0 into a veth that has an ife encode action on its ingress hook panics without this patch: skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000 data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3 kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657) tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874) tc_run (net/core/dev.c:4463) netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522) tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328) tcf_mirred_act (net/sched/act_mirred.c:489) tc_run (net/core/dev.c:4463) process_backlog (net/core/dev.c:6728) With Ethernet framing guaranteed, use ETH_HLEN instead of hard_header_len.

CVSS
—
Awaiting analysis by NVD
Timeline (UTC)
Published: 2026-09-17 17:16
Modified: 2026-10-21 13:20
NVD status: Received
Last synced 2 days ago
Verified against the source API 2026-10-27 06:54 UTC
Exploitation
Not listed in CISA KEV (as of last catalog sync)
Absence from KEV does not mean a CVE is not exploited. Exploitation status: unknown (no authoritative evidence in our sources).

Affected products

Not reported by the source (unknown — not "none").

Mitigation & advisories

No vendor advisory or patch reference tagged by NVD. Check the references below.

References

Data sources

NVD CVE API 2.0 — fetched 2026-10-27 06:54 UTC · record ↗

Learn the basics

Understanding CVEs and CVSS Scores