GHSA-PJM2-H6FG-MFW7

Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-24 18:32
VLAI
Details

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

net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()

syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit() when accessing skb->len for tx statistics after usb_submit_urb() has been called:

BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712 Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226

The URB completion handler write_bulk_callback() frees the skb via dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU in softirq context before usb_submit_urb() returns in the submitter, so by the time the submitter reads skb->len the skb has already been queued to the per-CPU completion_queue and freed by net_tx_action():

CPU A (xmit) CPU B (USB completion softirq) ------------ ------------------------------ dev->tx_skb = skb; usb_submit_urb() --+ |-------> write_bulk_callback() | dev_kfree_skb_irq(dev->tx_skb) | net_tx_action() | napi_skb_cache_put() <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read

Fix it by caching skb->len before submitting the URB and using the cached value when updating the tx_bytes counter.

The pre-existing tx_bytes semantics are preserved: the counter tracks the original frame length (skb->len), not the ETH_ZLEN/USB-alignment padded "count" value that is handed to the device. Changing that would be a user-visible accounting change and is out of scope for this UAF fix.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52982"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T17:17:08Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()\n\nsyzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()\nwhen accessing skb-\u003elen for tx statistics after usb_submit_urb() has\nbeen called:\n\n  BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760\n    drivers/net/usb/rtl8150.c:712\n  Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226\n\nThe URB completion handler write_bulk_callback() frees the skb via\ndev_kfree_skb_irq(dev-\u003etx_skb). The URB may complete on another CPU\nin softirq context before usb_submit_urb() returns in the submitter,\nso by the time the submitter reads skb-\u003elen the skb has already been\nqueued to the per-CPU completion_queue and freed by net_tx_action():\n\n  CPU A (xmit)                      CPU B (USB completion softirq)\n  ------------                      ------------------------------\n  dev-\u003etx_skb = skb;\n  usb_submit_urb()      --+\n                          |-------\u003e write_bulk_callback()\n                          |           dev_kfree_skb_irq(dev-\u003etx_skb)\n                          |         net_tx_action()\n                          |           napi_skb_cache_put()   \u003c-- free\n  netdev-\u003estats.tx_bytes  |\n    += skb-\u003elen;          \u003c-- UAF read\n\nFix it by caching skb-\u003elen before submitting the URB and using the\ncached value when updating the tx_bytes counter.\n\nThe pre-existing tx_bytes semantics are preserved: the counter tracks\nthe original frame length (skb-\u003elen), not the ETH_ZLEN/USB-alignment\npadded \"count\" value that is handed to the device.  Changing that\nwould be a user-visible accounting change and is out of scope for\nthis UAF fix.",
  "id": "GHSA-pjm2-h6fg-mfw7",
  "modified": "2026-06-24T18:32:42Z",
  "published": "2026-06-24T18:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52982"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/23f0e34c64acba15cad4d23e50f41f533da195fa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/24831b0b2ada9fef18d1f486b7b7c444ee5ba637"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30cf9829d09ca958279c937af8e35495cd2f1e09"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/423b5b86e14e190f6e3161eb5f2ea5f908295ba7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4dd7eb94f79486b77ca6b4c8676aedbc465dc802"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5af290c86fa81ddbc86a08d54229af5daa40c6a4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5db090ca07b28a63fb1499690cf19a3f3adafacb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6999d70e0eda39af029fa1891c48f0a8832b09d5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…