CVE-2026-98739: Bluetooth: RFCOMM: Fix initial port reference race
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Fix initial port reference race
For RFCOMMRELEASEONHUP devices, rfcommttyinstall() and rfcommreleasedev() both use RFCOMMTTYOWNED to decide who drops the initial ttyport reference. The release path tests the bit separately from the install path setting it, so both can drop that reference.
The synchronous hangup does not prevent this race: port->tty is not assigned until ttyportopen(), after installation. The following interleaving is possible:
1. Install and release each obtain a reference with rfcommdevget(). 2. Release observes RFCOMMTTYOWNED clear. 3. Install sets RFCOMMTTYOWNED and drops the initial reference. 4. Release drops the same initial reference again. 5. TTY cleanup drops its reference and frees the device. 6. Release performs its final ttyportput() on the freed port.
KASAN reported:
BUG: KASAN: slab-use-after-free in ttyportput+0x22/0x190 Write of size 4 at addr ffff8881001d3d5c by task poc/92
Call Trace: ttyportput+0x22/0x190 rfcommdevioctl+0x1d4/0x1930 sockdoioctl+0x110/0x260 sockioctl+0x380/0x590 x64sysioctl+0x134/0x1c0
Allocated by task 88: rfcommdevioctl+0x8f6/0x1930 sockdoioctl+0x110/0x260 sockioctl+0x380/0x590 x64sysioctl+0x134/0x1c0
Freed by task 65: kfree+0x131/0x3c0 rfcommdevdestruct+0x23b/0x2f0 releaseonetty+0xc1/0x370 processonework+0x661/0x1090
Use testandsetbit() in both paths so that only the caller that changes RFCOMMTTYOWNED from clear to set drops the initial reference. Each path keeps its own lookup reference until release or TTY cleanup, preserving the existing callback ordering and error handling.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the RFCOMM install and release paths, use test_and_set_bit() for RFCOMM_TTY_OWNED so only the caller that changes the bit drops the initial tty_port reference.