{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003edev-\u003ehard_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-\u003edev-\u003etype 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-\u003edev 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.",
  "id": "DEBIAN-CVE-2026-90083",
  "modified": "2026-09-18T04:47:39.178764851Z",
  "published": "2026-09-17T17:16:57.707Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-90083"
    }
  ],
  "upstream": [
    "CVE-2026-90083"
  ]
}