GHSA-4HXP-VHHR-H77F

Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-09-17 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_skbmod: fix length calculations and avoid invalid header warnings

syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act():

!skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55

There are a few issues in tcf_skbmod_act():

  1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress.
  2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length.
  3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets).

Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-90078"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T17:16:57Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_skbmod: fix length calculations and avoid invalid header warnings\n\nsyzbot reported a warning in skb_network_header_len() triggered\nby tcf_skbmod_act():\n\n  !skb_transport_header_was_set(skb)\n  WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline]\n  WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55\n\nThere are a few issues in tcf_skbmod_act():\n\n1. Calling skb_network_header_len() assumes skb-\u003etransport_header is set,\n   which is not guaranteed when tcf_skbmod_act() runs at TC ingress.\n2. Unconditionally calling skb_mac_header_len() at the beginning of\n   tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the\n   MAC header is unset, evaluating to an underflowed garbage length.\n3. On TC ingress, skb-\u003edata points to the network header. Adding the MAC\n   header length to the IP header length causes skb_ensure_writable() to\n   request more bytes than the actual IP packet length, dropping valid\n   short packets (e.g. 28-byte UDP/IPv4 packets).\n\nFix these by:\n- Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for\n  SKBMOD_F_ECN so that the required length is correctly calculated on\n  both ingress (offset == 0) and egress (offset == mac_len).\n- Setting max_edit_len to ETH_HLEN for Ethernet header modifications\n  after validating ARPHRD_ETHER.",
  "id": "GHSA-4hxp-vhhr-h77f",
  "modified": "2026-09-17T18:31:50Z",
  "published": "2026-09-17T18:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90078"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0675cff3c2924eb9b80d9dd250cf56a1140af157"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1719865b20b22c88d2a55e922eff5ca31b0841f6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/62126464f3a6159c0a3dd89e196ba65bfeb0afc6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/81d0d1e64f30d9989c829c0953cd6e6c68d9c5fb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/985a37781ade19061400100c2ba0f43979dd4d63"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d896843d8d925f0adbba319020595cfb1a7bcd57"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e8a2027b7e686784a69b2dfcee841d779919f313"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.