CVE-2026-98739: Bluetooth: RFCOMM: Fix initial port reference race
Bluetooth: RFCOMM: Fix initial port reference race
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.161.1-1
Event History
Frequently Asked Questions
Which systems are exposed to this race?
The race is described for RFCOMM devices using RFCOMM_RELEASE_ONHUP. The provided information does not state whether this mode is enabled by default or identify affected kernel versions.
What timing is required to trigger the issue?
Installation of the RFCOMM TTY and device release must overlap while both paths hold references to the device. The release path can observe RFCOMM_TTY_OWNED as clear before the install path sets it, allowing both paths to drop the same initial tty_port reference.
Does a synchronous hangup prevent exploitation?
No. The synchronous hangup does not prevent the race because port->tty is assigned only later, during tty_port_open(), after installation.
How might the issue appear in diagnostics?
KASAN may report a slab use-after-free in tty_port_put, with a call trace including rfcomm_dev_ioctl, sock_do_ioctl, and sock_ioctl. The failing final tty_port_put() occurs after the device and port have already been freed.