CVE-2026-90088: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Validate MTU in rfcommapplypn() to prevent infinite loop
rfcommapplypn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == mint(sizet, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory.
Fix by clamping d->mtu to RFCOMMDEFAULTMTU when the negotiated value is zero, consistent with the initial value assigned in rfcommdlcalloc().
Affected Software
Event History
Frequently Asked Questions
What does an attacker need to trigger the issue?
The attacker must act as a remote Bluetooth RFCOMM peer and send a Parameter Negotiation frame with an MTU value of zero. The vulnerable system must then use the affected RFCOMM sendmsg fragmentation path.
What is the operational impact of successful exploitation?
Sending with the negotiated zero MTU causes fragmentation to make no progress, repeatedly allocating zero-length skbs. This can exhaust all system memory.