CVE-2026-98739
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A flaw in how Linux handles certain Bluetooth connections could let someone on the same computer crash the system or potentially run harmful code.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
A race condition in RFCOMM TTY handling allows concurrent install and release paths to both drop the initial tty_port reference, resulting in a use-after-free vulnerability when tty_port_put is called on a freed port.
Why it matters to the business
Systems running affected Linux kernels with Bluetooth RFCOMM enabled may experience kernel crashes or memory corruption, leading to denial of service or potential code execution if exploited by a local attacker.
How an attack unfolds
An attacker with local access triggers the race by performing Bluetooth RFCOMM device operations that interleave rfcomm_tty_install and release paths, causing double decrement of the port reference and subsequent use-after-free when the port is freed.
How to fix it
Update to a Linux kernel version that includes the fix using test_and_set_bit for RFCOMM_TTY_OWNED.
How to confirm the fix worked
Verify the presence of the patch that replaces separate bit tests with test_and_set_bit in rfcomm_tty_install and __rfcomm_release_dev. Check kernel source or apply KASAN testing to confirm no UAF.
Typical attack path
- Obtain local access to the system
- Interact with Bluetooth RFCOMM via ioctls or socket operations to trigger concurrent install and release
- Trigger the race condition to cause double reference drop
- Observe or exploit the resulting use-after-free
How to detect it
Look for KASAN reports mentioning slab-use-after-free in tty_port_put called from rfcomm_dev_ioctl in kernel logs.
- BUG: KASAN: slab-use-after-free in tty_port_put
- rfcomm_dev_ioctl
- tty_port_put+0x22/0x190
What your security team should do
- Apply kernel updates promptly to address the race condition
- Disable Bluetooth RFCOMM if not required for operations
- Monitor kernel logs for use-after-free reports involving tty_port_put and rfcomm_dev_ioctl
The record
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix initial port reference race For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install() and __rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the initial tty_port 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 tty_port_open(), after installation. The following interleaving is possible: 1. Install and release each obtain a reference with rfcomm_dev_get(). 2. Release observes RFCOMM_TTY_OWNED clear. 3. Install sets RFCOMM_TTY_OWNED 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 tty_port_put() on the freed port. KASAN reported: BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190 Write of size 4 at addr ffff8881001d3d5c by task poc/92 Call Trace: tty_port_put+0x22/0x190 rfcomm_dev_ioctl+0x1d4/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 88: rfcomm_dev_ioctl+0x8f6/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0 Freed by task 65: kfree+0x131/0x3c0 rfcomm_dev_destruct+0x23b/0x2f0 release_one_tty+0xc1/0x370 process_one_work+0x661/0x1090 Use test_and_set_bit() in both paths so that only the caller that changes RFCOMM_TTY_OWNED 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 packages
| Ecosystem | Package | Introduced | Fixed |
|---|