CVE-2026-64442

In the Linux kernel, the following vulnerability has been resolved:

staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl()

Two IE parsing loops are missing the header bounds checks before they dereference pIE->length:

• issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer.

• join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions.

Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue.

Apply the two-guard pattern established in update_beacon_info():

1. Break if fewer than sizeof(*pIE) bytes remain.
2. Break if the IEs declared data extends past the buffer end.

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/540.html

References

• https://git.kernel.org/stable/c/402f13ec95945f34a210b28df1f8740d3d4a58c5
• https://git.kernel.org/stable/c/4c21eec80cf502d9ea18e0b946246b2376452786
• https://git.kernel.org/stable/c/605ebd94d0f469204f3c9f2f84acc71e43e2780f
• https://git.kernel.org/stable/c/a830bdc82461353bf7b1f8a2ad2689bf5d2de444
• https://git.kernel.org/stable/c/ad2637c46ef8b8ae0894372a2d39fdfcdc420a1e
• https://git.kernel.org/stable/c/bc881c9915c4468747d0ca5fd1abd7b313cfb0f4
• https://git.kernel.org/stable/c/c38d16b1ffac385c9e4b38447cd5c46af1114b58
• https://git.kernel.org/stable/c/ef61d628dfad38fead1fd2e08979ae9126d011d5