CVE-2026-93783: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame

Published Sep 24, 2026
·
Updated

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

Bluetooth: RFCOMM: validate skb length in rfcommrecvframe

rfcommrecvframe() casts skb->data to struct rfcommhdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINTMAX, making skbtailpointer() read far past the buffer.

Commit 23882b828c3c ("Bluetooth: RFCOMM: validate skb length in MCC handlers") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcommrecvframe() was left unfixed. KMSAN reports:

BUG: KMSAN: uninit-value in rfcommrun ... Uninit was created at: allocskb+0x474/0xb60 vhciwrite+0xe9/0x870

Fix this by rejecting frames smaller than sizeof(struct rfcommhdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).

Affected Software

1 affected component
Linux Linux kernel

Event History

Sep 24, 2026
CVE Published
via MITRE·04:02 PM
Data Sourced
via MITRE·04:02 PM
Description
Data Sourced
via NVD·05:17 PM
Description

Frequently Asked Questions

1

What does an attacker need to send to trigger the vulnerable code path?

The attacker needs to cause the RFCOMM receive path to process a malformed Bluetooth frame shorter than the minimum valid frame length. This includes a frame shorter than the 3-byte RFCOMM header plus 1-byte FCS, and specifically a zero-length frame.

2

What happens when a zero-length RFCOMM frame is processed?

The receive code decrements skb->len without first confirming that data is present, causing the length to underflow to UINT_MAX. Subsequent access through skb_tail_pointer() can then read far beyond the packet buffer.

3

How can this issue be mitigated if the fix cannot be deployed immediately?

The provided information does not specify a configuration workaround. Mitigation would need to prevent malformed RFCOMM frames from reaching the affected Linux kernel Bluetooth RFCOMM receive path.

4

How can administrators identify evidence of this issue?

KMSAN may report an uninitialized-value error in rfcomm_run. The report can trace the uninitialized data to skb allocation, including allocations associated with vhci_write.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203