CVE-2026-100076: staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix xmitframe/xmitbuf leaks on mgnt-frame error paths
issuebeacon(), issueprobersp() and issueasocrsp() obtain a management xmitframe together with its xmitbuf from the driver's fixed-size management-TX pools via allocmgtxmitframe(). On the normal path the frame is handed to dumpmgntframe(), which transfers ownership and eventually returns both objects to their pools (the frame and, for beacons, the buf in rtl8723bsmgntxmit(); other bufs via the pending-xmitbuf/TX-completion path).
Several error/edge paths return early after a successful allocmgtxmitframe() but before dumpmgntframe(), so ownership is never transferred and neither object is freed:
- issuebeacon(): beacon larger than 512 bytes - issueprobersp(): curnetwork->ielength > MAXIESZ - issueprobersp(): kzalloc() of the SSID scratch buffer fails - issueasocrsp(): pkttype is neither ASSOCRSP nor REASSOCRSP
Because allocmgtxmitframe() removes the frame and buf from their free lists (listdelinit) without placing them on any pending list, an orphaned pair is on no list and referenced by nobody, so it is only reclaimed at driver teardown. Repeated hits progressively exhaust the management-TX pools until allocmgtxmitframe() returns NULL and the interface can no longer send beacons or probe/assoc responses.
Free the frame and buffer on these paths, matching the existing correct error handling in issueassocreq().
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's staging rtl8723bs wireless driver are exposed when its management-frame paths call issue_beacon(), issue_probersp(), or issue_asocrsp(). The issue concerns management transmit-frame and transmit-buffer pools maintained by that driver.
What conditions trigger the resource leak?
The leak occurs after alloc_mgtxmitframe() succeeds but before ownership is passed to dump_mgntframe(). Documented triggers are an oversized beacon larger than 512 bytes, cur_network->ie_length exceeding MAX_IE_SZ, failure to allocate the SSID scratch buffer, or an association-response packet type that is neither ASSOCRSP nor REASSOCRSP.
What is the operational effect of repeated triggering?
Each affected error path can orphan a management transmit frame and its associated transmit buffer, removing both from the driver's fixed-size free pools without returning them or placing them on a pending list. The objects are then not reclaimed through the normal driver paths, so repeated occurrences can deplete the available management-TX pool.
How can an affected system be identified?
The relevant indicators are execution of the rtl8723bs management-frame error paths after a successful alloc_mgtxmitframe() call, particularly the listed oversized, allocation-failure, or invalid packet-type conditions. The orphaned frame and buffer are not present on the free or pending lists and are not referenced by normal driver ownership paths.