CVE-2026-52982

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

State
Published
Severity
9.8 Critical
Published
Jun 24, 2026
Updated
Oct 19, 2026
Reserved
Jun 9, 2026

Read the record on cve.org

Description

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.

Scores

CVSSScoreVectorSource
3.19.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HLinux

Weaknesses

Affected Products

ProductVersions
LinuxLinux
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 5af290c86fa81ddbc86a08d54229af5daa40c6a4Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 24831b0b2ada9fef18d1f486b7b7c444ee5ba637Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 423b5b86e14e190f6e3161eb5f2ea5f908295ba7Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 5db090ca07b28a63fb1499690cf19a3f3adafacbAffected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 30cf9829d09ca958279c937af8e35495cd2f1e09Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 6999d70e0eda39af029fa1891c48f0a8832b09d5Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 4dd7eb94f79486b77ca6b4c8676aedbc465dc802Affected
  • 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 to before 23f0e34c64acba15cad4d23e50f41f533da195faAffected
LinuxLinux
  • 2.6.12Affected
  • before 2.6.12Not affected
  • 5.10.258 through 5.10.*Not affected
  • 5.15.209 through 5.15.*Not affected
  • 6.1.175 through 6.1.*Not affected
  • 6.6.141 through 6.6.*Not affected
  • 6.12.91 through 6.12.*Not affected
  • 6.18.33 through 6.18.*Not affected
  • 7.0.10 through 7.0.*Not affected
  • 7.1 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.