Vulnerability-Lookup

GHSA-4CRX-J28M-6WRF

Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31

Details

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

net/packet: guard the ll header push in packet_rcv_spkt()

packet_rcv_spkt() restores the link layer header with

skb_push(skb, skb->data - skb_mac_header(skb));

That subtraction is only meaningful when the device actually has a link layer header. packet_rcv() and tpacket_rcv() both wrap it in dev_has_header(), which is also the predicate the block comment at the top of the file states the restore in terms of; packet_rcv_spkt() does not. commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header") introduced the helper and changed the two call sites, and this one stayed behind.

A device without a visible ll header can leave skb->mac_header at the 0xFFFF sentinel that _alloc_skb() initialises it to. A CAN skb does: init_can_skb() sets pkt_type and ip_summed but does not reset the headers, and commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") dropped the skb_reset*_header() calls that used to be there. skb_mac_header() is then 0xFFFF, the length becomes a large negative number and skb_push() reports it through skb_under_panic() -- from softirq context, so it is a full system panic even with panic_on_oops=0:

skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x50/0x60 Call Trace: skb_push+0x38/0x40 packet_rcv_spkt+0xe1/0x170 __netif_receive_skb_core.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt

The socket type is reachable: packet_create() accepts SOCK_PACKET alongside SOCK_RAW and SOCK_DGRAM behind the same CAP_NET_RAW check, and neither the socket length nor a capability check keeps it away from a CAN interface.

The missing skb_reset_*_header() calls in init_can_skb() are a regression in their own right and are being fixed separately, but a packet socket should not turn a link layer that did not initialise its mac header into a kernel panic. Guard the push the way the other two receive paths do.

Tested on v7.3-rc5 under QEMU with a slcan device on a pty, which is the driver RX path: vcan does not reproduce it, because can_send() resets the headers on the way out. One SOCK_PACKET socket bound to can0 and one frame written into the line discipline panics an unpatched kernel with the trace above; the same image with this patch prints no panic and powers off normally. Both kernels are this tree, defconfig plus CONFIG_CAN_SLCAN=y, differing only in this hunk.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-99033"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-23T13:17:26Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: guard the ll header push in packet_rcv_spkt()\n\npacket_rcv_spkt() restores the link layer header with\n\n\tskb_push(skb, skb-\u003edata - skb_mac_header(skb));\n\nThat subtraction is only meaningful when the device actually has a link\nlayer header.  packet_rcv() and tpacket_rcv() both wrap it in\ndev_has_header(), which is also the predicate the block comment at the\ntop of the file states the restore in terms of; packet_rcv_spkt() does\nnot.  commit d549699048b4 (\"net/packet: fix packet receive on L3\ndevices without visible hard header\") introduced the helper and changed\nthe two call sites, and this one stayed behind.\n\nA device without a visible ll header can leave skb-\u003emac_header at the\n0xFFFF sentinel that __alloc_skb() initialises it to.  A CAN skb does:\ninit_can_skb() sets pkt_type and ip_summed but does not reset the\nheaders, and commit 9f10374bb024 (\"can: remove private CAN skb\nheadroom infrastructure\") dropped the skb_reset_*_header() calls that\nused to be there.  skb_mac_header() is then 0xFFFF, the length becomes\na large negative number and skb_push() reports it through\nskb_under_panic() -- from softirq context, so it is a full system panic\neven with panic_on_oops=0:\n\n  skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0\n  kernel BUG at net/core/skbuff.c:214!\n  RIP: 0010:skb_panic+0x50/0x60\n  Call Trace:\n   \u003cIRQ\u003e\n   skb_push+0x38/0x40\n   packet_rcv_spkt+0xe1/0x170\n   __netif_receive_skb_core.constprop.0+0x7e8/0xd30\n   ...\n  Kernel panic - not syncing: Fatal exception in interrupt\n\nThe socket type is reachable: packet_create() accepts SOCK_PACKET\nalongside SOCK_RAW and SOCK_DGRAM behind the same CAP_NET_RAW check,\nand neither the socket length nor a capability check keeps it away\nfrom a CAN interface.\n\nThe missing skb_reset_*_header() calls in init_can_skb() are a\nregression in their own right and are being fixed separately, but a\npacket socket should not turn a link layer that did not initialise its\nmac header into a kernel panic.  Guard the push the way the other two\nreceive paths do.\n\nTested on v7.3-rc5 under QEMU with a slcan device on a pty, which is\nthe driver RX path: vcan does not reproduce it, because can_send()\nresets the headers on the way out.  One SOCK_PACKET socket bound to\ncan0 and one frame written into the line discipline panics an\nunpatched kernel with the trace above; the same image with this patch\nprints no panic and powers off normally.  Both kernels are this tree,\ndefconfig plus CONFIG_CAN_SLCAN=y, differing only in this hunk.",
  "id": "GHSA-4crx-j28m-6wrf",
  "modified": "2026-10-23T15:31:35Z",
  "published": "2026-10-23T15:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99033"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/00fbf71e74115f7628fc0880b855434b1e70c40c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/28bc1ef699610ee09ce3d46a00552f5a0a0144bd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/31c7b15b3716e8d0dad58d2c3cdf321dfd06f4be"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3efe0e0944157fdd2072b4dc7eb0491a317ed272"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d8a24b9e1774a93943caf68d48c5e17be432220b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2026-99033 (GCVE-0-2026-99033)

Vulnerability from cvelistv5 – Published: 2026-10-23 12:21 – Updated: 2026-10-23 12:21

Title

net/packet: guard the ll header push in packet_rcv_spkt()

Summary

In the Linux kernel, the following vulnerability has been resolved: net/packet: guard the ll header push in packet_rcv_spkt() packet_rcv_spkt() restores the link layer header with skb_push(skb, skb->data - skb_mac_header(skb)); That subtraction is only meaningful when the device actually has a link layer header. packet_rcv() and tpacket_rcv() both wrap it in dev_has_header(), which is also the predicate the block comment at the top of the file states the restore in terms of; packet_rcv_spkt() does not. commit d549699048b4 ("net/packet: fix packet receive on L3 devices without visible hard header") introduced the helper and changed the two call sites, and this one stayed behind. A device without a visible ll header can leave skb->mac_header at the 0xFFFF sentinel that __alloc_skb() initialises it to. A CAN skb does: init_can_skb() sets pkt_type and ip_summed but does not reset the headers, and commit 9f10374bb024 ("can: remove private CAN skb headroom infrastructure") dropped the skb_reset_*_header() calls that used to be there. skb_mac_header() is then 0xFFFF, the length becomes a large negative number and skb_push() reports it through skb_under_panic() -- from softirq context, so it is a full system panic even with panic_on_oops=0: skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0 kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x50/0x60 Call Trace: <IRQ> skb_push+0x38/0x40 packet_rcv_spkt+0xe1/0x170 __netif_receive_skb_core.constprop.0+0x7e8/0xd30 ... Kernel panic - not syncing: Fatal exception in interrupt The socket type is reachable: packet_create() accepts SOCK_PACKET alongside SOCK_RAW and SOCK_DGRAM behind the same CAP_NET_RAW check, and neither the socket length nor a capability check keeps it away from a CAN interface. The missing skb_reset_*_header() calls in init_can_skb() are a regression in their own right and are being fixed separately, but a packet socket should not turn a link layer that did not initialise its mac header into a kernel panic. Guard the push the way the other two receive paths do. Tested on v7.3-rc5 under QEMU with a slcan device on a pty, which is the driver RX path: vcan does not reproduce it, because can_send() resets the headers on the way out. One SOCK_PACKET socket bound to can0 and one frame written into the line discipline panics an unpatched kernel with the trace above; the same image with this patch prints no panic and powers off normally. Both kernels are this tree, defconfig plus CONFIG_CAN_SLCAN=y, differing only in this hunk.

Severity

No CVSS data available.

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 7056 records in the last 180 days details

References

5 references

URL	Tags
https://git.kernel.org/stable/c/d8a24b9e1774a9394…
https://git.kernel.org/stable/c/31c7b15b3716e8d0d…
https://git.kernel.org/stable/c/3efe0e0944157fdd2…
https://git.kernel.org/stable/c/00fbf71e74115f762…
https://git.kernel.org/stable/c/28bc1ef699610ee09…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: d549699048b4b5c22dd710455bcdb76966e55aa3 , < d8a24b9e1774a93943caf68d48c5e17be432220b (git) Affected: d549699048b4b5c22dd710455bcdb76966e55aa3 , < 31c7b15b3716e8d0dad58d2c3cdf321dfd06f4be (git) Affected: d549699048b4b5c22dd710455bcdb76966e55aa3 , < 3efe0e0944157fdd2072b4dc7eb0491a317ed272 (git) Affected: d549699048b4b5c22dd710455bcdb76966e55aa3 , < 00fbf71e74115f7628fc0880b855434b1e70c40c (git) Affected: d549699048b4b5c22dd710455bcdb76966e55aa3 , < 28bc1ef699610ee09ce3d46a00552f5a0a0144bd (git) Affected: dadddde259a19105ee69e788835f4d4552767aa9 (git) Affected: 5.9.13 , < 5.10 (semver)
Linux	Linux	Affected: 5.10 Unaffected: 0 , < 5.10 (semver) Unaffected: 6.6.160 , ≤ 6.6.* (semver) Unaffected: 6.12.113 , ≤ 6.12.* (semver) Unaffected: 6.18.57 , ≤ 6.18.* (semver) Unaffected: 7.2.11 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/packet/af_packet.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d8a24b9e1774a93943caf68d48c5e17be432220b",
              "status": "affected",
              "version": "d549699048b4b5c22dd710455bcdb76966e55aa3",
              "versionType": "git"
            },
            {
              "lessThan": "31c7b15b3716e8d0dad58d2c3cdf321dfd06f4be",
              "status": "affected",
              "version": "d549699048b4b5c22dd710455bcdb76966e55aa3",
              "versionType": "git"
            },
            {
              "lessThan": "3efe0e0944157fdd2072b4dc7eb0491a317ed272",
              "status": "affected",
              "version": "d549699048b4b5c22dd710455bcdb76966e55aa3",
              "versionType": "git"
            },
            {
              "lessThan": "00fbf71e74115f7628fc0880b855434b1e70c40c",
              "status": "affected",
              "version": "d549699048b4b5c22dd710455bcdb76966e55aa3",
              "versionType": "git"
            },
            {
              "lessThan": "28bc1ef699610ee09ce3d46a00552f5a0a0144bd",
              "status": "affected",
              "version": "d549699048b4b5c22dd710455bcdb76966e55aa3",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "dadddde259a19105ee69e788835f4d4552767aa9",
              "versionType": "git"
            },
            {
              "lessThan": "5.10",
              "status": "affected",
              "version": "5.9.13",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/packet/af_packet.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.10"
            },
            {
              "lessThan": "5.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.160",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.113",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.57",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.11",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.160",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.113",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.57",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.11",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "5.9.13",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: guard the ll header push in packet_rcv_spkt()\n\npacket_rcv_spkt() restores the link layer header with\n\n\tskb_push(skb, skb-\u003edata - skb_mac_header(skb));\n\nThat subtraction is only meaningful when the device actually has a link\nlayer header.  packet_rcv() and tpacket_rcv() both wrap it in\ndev_has_header(), which is also the predicate the block comment at the\ntop of the file states the restore in terms of; packet_rcv_spkt() does\nnot.  commit d549699048b4 (\"net/packet: fix packet receive on L3\ndevices without visible hard header\") introduced the helper and changed\nthe two call sites, and this one stayed behind.\n\nA device without a visible ll header can leave skb-\u003emac_header at the\n0xFFFF sentinel that __alloc_skb() initialises it to.  A CAN skb does:\ninit_can_skb() sets pkt_type and ip_summed but does not reset the\nheaders, and commit 9f10374bb024 (\"can: remove private CAN skb\nheadroom infrastructure\") dropped the skb_reset_*_header() calls that\nused to be there.  skb_mac_header() is then 0xFFFF, the length becomes\na large negative number and skb_push() reports it through\nskb_under_panic() -- from softirq context, so it is a full system panic\neven with panic_on_oops=0:\n\n  skbuff: skb_under_panic: text:ffffffff8bd21bc1 len:-65455 put:-65471 head:... data:... tail:0x50 end:0x180 dev:can0\n  kernel BUG at net/core/skbuff.c:214!\n  RIP: 0010:skb_panic+0x50/0x60\n  Call Trace:\n   \u003cIRQ\u003e\n   skb_push+0x38/0x40\n   packet_rcv_spkt+0xe1/0x170\n   __netif_receive_skb_core.constprop.0+0x7e8/0xd30\n   ...\n  Kernel panic - not syncing: Fatal exception in interrupt\n\nThe socket type is reachable: packet_create() accepts SOCK_PACKET\nalongside SOCK_RAW and SOCK_DGRAM behind the same CAP_NET_RAW check,\nand neither the socket length nor a capability check keeps it away\nfrom a CAN interface.\n\nThe missing skb_reset_*_header() calls in init_can_skb() are a\nregression in their own right and are being fixed separately, but a\npacket socket should not turn a link layer that did not initialise its\nmac header into a kernel panic.  Guard the push the way the other two\nreceive paths do.\n\nTested on v7.3-rc5 under QEMU with a slcan device on a pty, which is\nthe driver RX path: vcan does not reproduce it, because can_send()\nresets the headers on the way out.  One SOCK_PACKET socket bound to\ncan0 and one frame written into the line discipline panics an\nunpatched kernel with the trace above; the same image with this patch\nprints no panic and powers off normally.  Both kernels are this tree,\ndefconfig plus CONFIG_CAN_SLCAN=y, differing only in this hunk."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-23T12:21:37.662Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d8a24b9e1774a93943caf68d48c5e17be432220b"
        },
        {
          "url": "https://git.kernel.org/stable/c/31c7b15b3716e8d0dad58d2c3cdf321dfd06f4be"
        },
        {
          "url": "https://git.kernel.org/stable/c/3efe0e0944157fdd2072b4dc7eb0491a317ed272"
        },
        {
          "url": "https://git.kernel.org/stable/c/00fbf71e74115f7628fc0880b855434b1e70c40c"
        },
        {
          "url": "https://git.kernel.org/stable/c/28bc1ef699610ee09ce3d46a00552f5a0a0144bd"
        }
      ],
      "title": "net/packet: guard the ll header push in packet_rcv_spkt()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-99033",
    "datePublished": "2026-10-23T12:21:37.662Z",
    "dateReserved": "2026-09-25T10:25:14.387Z",
    "dateUpdated": "2026-10-23T12:21:37.662Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

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.

Action not permitted