CVE-2023-54036

What the vulnerability is

The rtl8xxxu driver in the Linux kernel contains two separate memory-leak bugs affecting the RTL8723BU and RTL8192EU chips. For RTL8723BU, frequent C2H (card-to-host) messages—generated particularly during Bluetooth audio activity—are enqueued but never freed because the dev_kfree_skb() call in rtl8xxxu_c2hcmd_callback() is placed outside the dequeuing loop. For RTL8192EU, a goto guard that checks rf_paths > 1 prevents all C2H processing, and since commit e542e66b7c2e ("wifi: rtl8xxxu: gen2: Turn on the rate control") now generates a C2H message on rate changes, those messages accumulate indefinitely. The RTL8188FU is theoretically at risk but is unlikely to trigger the bug in normal operation [1][2].

How it is exploited

Exploitation does not require attacker authentication or special network access; any legitimate Bluetooth audio connection to an RTL8723BU device, or simply normal rate-control changes on an RTL8192EU device, will cause the driver to leak C2H sk_buff objects. No specific attacker interaction is needed beyond regular usage that triggers C2H message generation. On RTL8723BU, the leakage rate increases with Bluetooth traffic, while on RTL8192EU even a single rate-change event can lead to a persistent leak because C2H messages are never consumed [1][2].

Impact

An attacker who can induce Bluetooth audio streaming (or any activity generating frequent C2H messages) on a system using RTL8723BU, or trigger rate changes on RTL8192EU, can gradually exhaust kernel memory. Over time, this leads to system instability, denial-of-service (DoS) for the WiFi interface, and potentially a complete system hang due to memory exhaustion. The impact is local but resource-exhaustion based, with no data exposure or privilege escalation [1][2].

Mitigation

Both bugs are fixed in the Linux kernel stable tree. For RTL8723BU, the fix moves dev_kfree_skb() inside the skb-dequeue loop; for RTL8192EU, the rf_paths > 1 guard is removed, allowing normal C2H processing. Users should update to a kernel containing either commit 430f9f9bec53 or commit b39f662ce1648 (both dated 2025-12-24). No workaround other than kernel patching exists [1][2].