CVE-2026-64443: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in updatebeaconinfo() IE loop
The IE parsing loop in updatebeaconinfo() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the elementid byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer.
Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions.
Add two guards at the top of the loop body: 1. Break if fewer than sizeof(pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len.
Also replace i += (pIE->length + 2) with i += sizeof(pIE) + pIE->length for consistency with the sizeof(pIE) guards added above.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.145.2-1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel rtl8723bs staging driver are exposed when they process Beacon frames from nearby wireless access points. The affected attack surface is network-adjacent, as reflected by the AV:A vector.
What must an attacker do to trigger the flaw?
An attacker needs to operate or impersonate a wireless access point that can send a crafted Beacon frame to the target. The malformed frame can end with an incomplete information-element header or declare information-element data extending beyond the received frame; no privileges or user interaction are required.
What is the impact of a successful trigger?
The vulnerable parser can read beyond the allocated receive buffer while processing Beacon information elements. The supplied severity data rates confidentiality and availability impact as high, with no integrity impact.
How can I determine whether the installed code contains the fix?
Check whether update_beacon_info() validates that a complete information-element header remains before reading it and verifies that the declared element data does not extend past the frame length. The fixed loop advances using sizeof(*pIE) plus the element length rather than a hard-coded 2-byte header size.