CVE-2026-52982

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()<br /> <br /> syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()<br /> when accessing skb-&gt;len for tx statistics after usb_submit_urb() has<br /> been called:<br /> <br /> BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760<br /> drivers/net/usb/rtl8150.c:712<br /> Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226<br /> <br /> The URB completion handler write_bulk_callback() frees the skb via<br /> dev_kfree_skb_irq(dev-&gt;tx_skb). The URB may complete on another CPU<br /> in softirq context before usb_submit_urb() returns in the submitter,<br /> so by the time the submitter reads skb-&gt;len the skb has already been<br /> queued to the per-CPU completion_queue and freed by net_tx_action():<br /> <br /> CPU A (xmit) CPU B (USB completion softirq)<br /> ------------ ------------------------------<br /> dev-&gt;tx_skb = skb;<br /> usb_submit_urb() --+<br /> |-------&gt; write_bulk_callback()<br /> | dev_kfree_skb_irq(dev-&gt;tx_skb)<br /> | net_tx_action()<br /> | napi_skb_cache_put() stats.tx_bytes |<br /> += skb-&gt;len; len before submitting the URB and using the<br /> cached value when updating the tx_bytes counter.<br /> <br /> The pre-existing tx_bytes semantics are preserved: the counter tracks<br /> the original frame length (skb-&gt;len), not the ETH_ZLEN/USB-alignment<br /> padded "count" value that is handed to the device. Changing that<br /> would be a user-visible accounting change and is out of scope for<br /> this UAF fix.