A flaw in the Linux kernel's RFCOMM implementation fails to enforce the correct length requirement for frames with an extended two‑byte length field when EA is zero. The kernel checks that the packet length is at least the size of the header plus one byte, but it does not require the additional byte mandated by the EA==0 condition. This allows a specially crafted four‑byte frame to bypass the initial test, causing the subsequent trimming and pull operations to fail while the return value is ignored. As a result, incomplete RFCOMM headers can be forwarded to user space as payload or control commands, potentially leading to application misbehavior or kernel instability.

All Linux kernel binaries running a configuration that includes Bluetooth RFCOMM support are potentially vulnerable. Systems that expose the RFCOMM interface—whether as system services or user‑mode applications—may accept malformed frames from any nearby Bluetooth device, making the issue relevant to all user space or kernel components that rely on RFCOMM.

Based on the description, it is inferred that the attack vector is a remote physical proximity attack via Bluetooth. The flaw can be triggered by an attacker sending a crafted short RFCOMM frame over an active Bluetooth link, requiring only that the attacker is within range of the target device. The EPSS score is below 1%, indicating a low likelihood of exploitation in the wild, and the CVSS score of 6.5 classifies the vulnerability as moderate severity. It is not listed in the CISA KEV catalog, suggesting no known large‑scale exploits yet, but the remote nature and simplicity of the packet manipulation mean that a local or adversarial attacker could still cause a denial of service or anomalous behavior.