CVE-2026-52982

What it actually does

This is a Linux kernel use-after-free condition in the rtl8150 USB Ethernet driver transmit path. During packet transmission, the driver submits a USB Request Block and then reads skb->len to update transmit byte statistics. Because the USB completion handler can run on another CPU before usb_submit_urb() returns, the associated socket buffer may already have been freed when the transmit path reads its length. The immediate vulnerable operation is a stale 4-byte read from freed kernel memory. In typical conditions this is most likely to produce kernel memory-safety warnings, corrupted network statistics, or a kernel crash when memory debugging or hardening detects the invalid access; reliable privilege escalation or remote code execution is not indicated by the available details.

Why it matters to the business

Systems that use the affected Linux kernel driver with Realtek RTL8150 USB Ethernet adapters may experience kernel instability or crashes during network transmission, creating availability risk for workstations, appliances, embedded systems, lab systems, or servers that rely on those USB network interfaces. The issue has low public exploitation likelihood based on the provided EPSS score and is not known to be in CISA KEV or ransomware campaigns, but it should still be addressed during normal kernel maintenance because kernel memory-safety defects can affect system reliability and may be difficult to diagnose after a crash.

How an attack unfolds

An attacker would need a way to exercise the rtl8150 transmit path on a system using the affected driver, typically by causing traffic to be sent through a Realtek RTL8150 USB Ethernet interface. The vulnerable race occurs when the driver stores the socket buffer for transmission, submits the USB request, and the USB completion path frees that buffer on another CPU before the original transmit function reads skb->len for statistics accounting. By repeatedly generating transmit activity and timing the completion path, the race can be triggered, causing a read from freed kernel memory. Based on the described bug, exploitation is primarily a local or adjacent-device reliability issue rather than a straightforward remote compromise primitive.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the rtl8150 fix that caches skb->len before usb_submit_urb() and uses the cached value for transmit byte accounting. If an immediate kernel update is not possible, reduce exposure by avoiding use of affected RTL8150 USB Ethernet adapters, removing or blacklisting the rtl8150 driver where operationally feasible, or replacing the adapter with hardware using a different maintained driver. Because fixed package versions were not provided, use the relevant Linux distribution, appliance vendor, or kernel stable branch advisory to identify the exact corrected kernel build.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the vendor kernel changelog, source package, or git history for the rtl8150 change that reads skb->len before usb_submit_urb() in drivers/net/usb/rtl8150.c. Verify whether the driver is in use with commands such as lsmod, modinfo rtl8150, ethtool -i <interface>, dmesg, and USB device inventory tools. After remediation, exercise traffic through any RTL8150 USB Ethernet interface and confirm there are no KASAN, slab-use-after-free, rtl8150_start_xmit, write_bulk_callback, or related kernel memory-safety messages in kernel logs.

Typical attack path

1. Identify a Linux system using the rtl8150 USB Ethernet driver with a compatible Realtek RTL8150 USB network adapter.
2. Generate or induce outbound traffic through the affected USB Ethernet interface.
3. Trigger repeated transmit operations so the driver calls rtl8150_start_xmit().
4. Race USB transmit completion against the transmit submitter path so the completion handler frees the skb before the submitter reads skb->len.
5. Cause a kernel use-after-free read, potentially resulting in KASAN reports, kernel warnings, statistics corruption, or a system crash.

How to detect it

Review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for evidence that the rtl8150 transmit path triggered a memory-safety failure. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel records, netconsole output, kdump/vmcore artifacts, panic/oops reports, and kernel sanitizers such as KASAN. Look for messages referencing slab-use-after-free, rtl8150_start_xmit, write_bulk_callback, dev_kfree_skb_irq, net_tx_action, napi_skb_cache_put, or drivers/net/usb/rtl8150.c. Also correlate repeated kernel warnings or crashes with the presence of Realtek RTL8150 USB Ethernet hardware and outbound network traffic over that interface. There are no public threat actor or ransomware links provided for this issue, so detection should focus on local crash and kernel memory-corruption telemetry rather than network exploit signatures.

• BUG: KASAN: slab-use-after-free in rtl8150_start_xmit
• slab-use-after-free in rtl8150_start_xmit
• rtl8150_start_xmit+
• drivers/net/usb/rtl8150.c:712
• write_bulk_callback()
• write_bulk_callback
• dev_kfree_skb_irq
• net_tx_action
• napi_skb_cache_put
• Read of size 4 at addr
• usb_submit_urb
• rtl8150
• KASAN: slab-use-after-free

What your security team should do

• Inventory Linux systems that use USB Ethernet adapters and identify any loading the rtl8150 driver.
• Prioritize patching systems where RTL8150 USB Ethernet is used for production connectivity, remote access, embedded operations, or unattended appliances.
• Apply the appropriate vendor kernel update or move to a fixed stable kernel branch as soon as operationally practical.
• Where patching is delayed, avoid use of RTL8150 adapters or blacklist the rtl8150 module if the device is not required.
• Monitor kernel logs for use-after-free, KASAN, panic, oops, or rtl8150-related messages that may indicate triggering of the flaw.
• Treat unexpected kernel crashes on systems using RTL8150 USB Ethernet as potentially related and preserve logs and crash dumps for analysis.