CVE-2026-93783 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame
rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr 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 UINT_MAX, making skb_tail_pointer() 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 rfcomm_recv_frame() was left unfixed. KMSAN reports:
BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870
Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel Bluetooth subsystem contains a critical input validation flaw within the RFCOMM protocol implementation, specifically in the rfcomm_recv_frame function. This vulnerability arises from a failure to verify the length of incoming socket buffers before attempting to parse their contents as structured data frames. The core technical issue is that the code directly casts the raw packet buffer pointer to a struct rfcomm_hdr structure and subsequently dereferences fields such as hdr->addr and hdr->ctrl without first ensuring that the buffer contains sufficient bytes to safely access these members. This lack of boundary checking creates two distinct failure modes depending on the nature of the malformed input received by the kernel.
In scenarios where an attacker or a malfunctioning device sends a truncated frame with a length smaller than the minimum required header size, the kernel performs an out-of-bounds read into uninitialized memory. Because the buffer does not contain valid data for the entire structure, the values retrieved are arbitrary and potentially sensitive if they overlap with other kernel structures in memory. This behavior is consistent with CWE-125, which describes Out-of-Bounds Read vulnerabilities where software reads beyond the end of a buffer. The presence of uninitialized data can lead to unpredictable system behavior or information leakage, as confirmed by Kernel Memory Sanitizer reports indicating uninit-value errors originating from this code path during socket allocation and write operations.
A second, potentially more severe consequence occurs when processing zero-length frames. In such cases, the kernel executes a decrement operation on the buffer length field which results in an integer underflow, wrapping the value to UINT_MAX. This massive positive number is then used by skb_tail_pointer() to calculate memory offsets for reading data far past the actual end of the allocated buffer. This constitutes another instance of out-of-bounds access with severe implications for system stability and security integrity. The combination of these two flaws allows a local or potentially remote attacker, depending on the exposure of the Bluetooth interface, to trigger kernel panics through denial of service conditions or to probe memory contents that should remain isolated from user-space processes.
This vulnerability represents a regression in defensive coding practices within the RFCOMM stack. A previous commit addressed similar missing-length-check bugs in MCC sub-handlers but inadvertently left the top-level rfcomm_recv_frame function unprotected against malformed input. The absence of this validation at the primary entry point for frame processing means that all subsequent parsing logic operates on untrusted data without preliminary sanity checks. This oversight highlights the importance of comprehensive coverage when patching related vulnerabilities, as partial fixes can leave critical attack surfaces exposed to exploitation by malicious actors capable of crafting specific packet sequences.
The operational impact of this vulnerability includes potential denial of service through kernel crashes and possible information disclosure via memory leaks. An attacker could exploit these flaws to destabilize the host system or extract sensitive data from kernel memory space, which is typically protected from direct user-space access. The severity is heightened by the fact that Bluetooth interfaces are often exposed in environments where physical proximity attacks are feasible, making this a relevant threat vector for devices with active wireless connectivity enabled without strict filtering of incoming protocol frames.
To mitigate this vulnerability, it is essential to apply kernel updates that include the fix validating frame lengths before parsing. The correct remediation involves rejecting any RFCOMM frames that are smaller than the sum of the header size and the Frame Check Sequence length, which totals four bytes for standard configurations but must be validated against sizeof(struct rfcomm_hdr) plus one byte as specified in the patch logic. System administrators should ensure their systems are patched to version containing commit 23882b828c3c or later updates that address this specific oversight. Additionally, deploying network segmentation and monitoring tools can help detect anomalous Bluetooth traffic patterns indicative of exploitation attempts targeting RFCOMM implementations.
From a threat modeling perspective aligned with the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with initial access or privilege escalation depending on the context of execution. The out-of-bounds read aligns with CWE-125 and can be leveraged in conjunction with other vulnerabilities to achieve arbitrary code execution if combined with exploitation primitives for heap corruption or control flow hijacking. Organizations should prioritize patching this issue as part of their routine vulnerability management lifecycle, ensuring that all Bluetooth stack components are updated to prevent both denial of service attacks and potential data exfiltration through memory disclosure channels.