{"cve":"CVE-2026-90083","nvd":{"published":"2026-09-17T17:16:57.707","modified":"2026-10-21T13:20:35.970","status":"Received","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ife: Only operate on Ethernet frames\n\nact_ife encapsulates/decapsulates the original Ethernet header and uses\nskb->dev->hard_header_len as the length of that header. That is only\ncorrect for Ethernet devices: on a device where hard_header_len does not\nmatch the L2 header that was actually pulled (PPP reports PPP_HDRLEN\nwhile nothing is stripped on ingress), the ingress skb_push()/skb_pull()\nuse the wrong length and can hit skb_under_panic when headroom is tight.\n\nIFE is Ethernet-only by design - it builds an outer ethhdr, rewrites\nh_source/h_dest/h_proto, and calls eth_type_trans() on decode - so\ninstead of trying to make the offsets work for arbitrary link types,\nsimply drop packets that do not carry an Ethernet header.\n\nChecking skb->dev->type alone is not enough. We have to cater for a\ncorner case where mirred can redirect an skb from a non-Ethernet device\nto an Ethernet one, and skb->dev then says nothing about the framing the\nskb actually has: an skb redirected from ppp0 reaches the target's ingress\nhook with mac_len 0 and no Ethernet header at all. So at ingress also\nrequire mac_len to be ETH_HLEN. On egress mac_len is not maintained, so\nthe device type is all we have; a bogus redirect there yields a malformed\nframe rather than an out-of-bounds push, and it would be malformed with or\nwithout IFE.\n\nThat corner case is not theoretical - redirecting from ppp0 into a veth\nthat has an ife encode action on its ingress hook panics without this\npatch:\n\n  skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000\n          data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3\n  kernel BUG at net/core/skbuff.c:214!\n  Call Trace:\n   skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657)\n   tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874)\n   tc_run (net/core/dev.c:4463)\n   netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522)\n   tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328)\n   tcf_mirred_act (net/sched/act_mirred.c:489)\n   tc_run (net/core/dev.c:4463)\n   process_backlog (net/core/dev.c:6728)\n\nWith Ethernet framing guaranteed, use ETH_HLEN instead of\nhard_header_len.","cvss_v4":null,"cvss_v3":null,"cwes":[],"references":["https://git.kernel.org/stable/c/138b0054021fd7d57bc3eb68b3f4e2bcec037849","https://git.kernel.org/stable/c/13dddf87a1f89557920f9b437a21ea0b7225f828","https://git.kernel.org/stable/c/5b483f7791b079bb97d411f1066652ff659207ff","https://git.kernel.org/stable/c/b951dd2fd5ede007474fc134ecb5639e1f86f5de","https://git.kernel.org/stable/c/d218ea7df6eba076171f2d4897a429a31f2139f0"],"products":[],"source":"nvd","synced_at":"2026-10-22T16:41:11.231219466+00:00"},"epss":{"cve":"CVE-2026-90083","score":0.00209,"percentile":0.1092,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}