CVE-2026-98455 - Vulnerability Details

- Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO

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.

Published: 2026-10-18

Score: n/a

EPSS: n/a

KEV: No

Impact:

Action:

Analysis

Impact

The flaw is a NULL pointer dereference inside the RFCOMM get socket option handler. When a Bluetooth socket that has already been disconnected and whose session object has been cleared is queried for connection information, the code unconditionally accesses a NULL session pointer. This triggers a kernel panic, crashing the system. The vulnerability is limited to a DoS effect—there is no direct code execution, but the resulting kernel crash can be used to deny service or create a foothold for further exploits after reboot.

Affected Systems

The issue resides in the Linux kernel’s Bluetooth RFCOMM subsystem. Any kernel version containing the vulnerable code path before the patch is affected, including recent releases such as 7.3.0-rc3 and earlier. The affected product is the general Linux kernel; patches are available through the kernel maintainers and should be applied to all installations that support Bluetooth RFCOMM.

Risk and Exploitability

The fault can be triggered by an attacker who can provoke a DISC command on an RFCOMM channel and then perform a getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO). Since the trigger can be performed over an established Bluetooth link, the attack vector is remote via Bluetooth. EPSS and KEV data are not available, and no CVSS score was disclosed, so precise exploitation probability cannot be quantified. Nonetheless, because the bug results in an unconditionally fatal error, its severity is high; a single successful exploitation will immediately collapse the kernel, resulting in a denial‑of‑service impact.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`bb23c0ab824653be4aa7dfca15b07b3059717004`	affected	< c3aee3fc1287c8a555baf3895959087cb0c33fe8
`bb23c0ab824653be4aa7dfca15b07b3059717004`	affected	< 4bf5ca47203049ce3648f750a53dcdc98bcc9e3e
`bb23c0ab824653be4aa7dfca15b07b3059717004`	affected	< 1c4f7e1177da2f229be04139c27e5370a1cfba52
`bb23c0ab824653be4aa7dfca15b07b3059717004`	affected	< 84ae3cfd7d3a63591a2eb4faa24faf678c6708aa
`bb23c0ab824653be4aa7dfca15b07b3059717004`	affected	< c7362f6a18ed167f52f08ce25eeec8a7818c5004
`bb23c0ab824653be4aa7dfca15b07b3059717004`	affected	< 8f5b30cc12c409ff62891e47ed51e6bf0945a3ea
`bb23c0ab824653be4aa7dfca15b07b3059717004`	affected	< 005b23d9e324fe5d0acbcfa70c625f2e81189046
`bb23c0ab824653be4aa7dfca15b07b3059717004`	affected	< 46f8ffd0a1f1eb6cbc94946a92c11ef601e228a1

Linux

affected

Version	Status	Constraints
`2.6.30`	affected	—
`0`	unaffected	< 2.6.30
`5.10.271`	unaffected	≤ 5.10.*
`5.15.222`	unaffected	≤ 5.15.*
`6.1.189`	unaffected	≤ 6.1.*
`6.6.158`	unaffected	≤ 6.6.*
`6.12.112`	unaffected	≤ 6.12.*
`6.18.55`	unaffected	≤ 6.18.*
`7.2.9`	unaffected	≤ 7.2.*
`7.3-rc5`	unaffected	≤ *

No data.

No data available yet.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

Update the Linux kernel to a version containing the RFCOMM NULL‑dereference fix; obtaining the patch from the kernel source commit referenced in the advisory
If an immediate kernel upgrade is not possible, disable the RFCOMM protocol by removing or blacklisting the rfcomm kernel module, or stop the Bluetooth service to prevent the vulnerability from being exercised
Configure the system to avoid the deferred‑setup path by setting the BT_DEFER_SETUP flag to 0 when creating RFCOMM sockets, ensuring the problematic code path is not executed

Generated by OpenCVE AI on October 18, 2026 at 16:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

No EPSS score available.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/005b23d9e324fe5d0acbcfa70c625f2e81189046
https://git.kernel.org/stable/c/1c4f7e1177da2f229be04139c27e5370a1cfba52
https://git.kernel.org/stable/c/46f8ffd0a1f1eb6cbc94946a92c11ef601e228a1
https://git.kernel.org/stable/c/4bf5ca47203049ce3648f750a53dcdc98bcc9e3e
https://git.kernel.org/stable/c/84ae3cfd7d3a63591a2eb4faa24faf678c6708aa
https://git.kernel.org/stable/c/8f5b30cc12c409ff62891e47ed51e6bf0945a3ea
https://git.kernel.org/stable/c/c3aee3fc1287c8a555baf3895959087cb0c33fe8
https://git.kernel.org/stable/c/c7362f6a18ed167f52f08ce25eeec8a7818c5004

History

Sun, 18 Oct 2026 17:15:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-476

Sun, 18 Oct 2026 15:30:00 +0000

Type	Values Removed	Values Added
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.
Title		Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/005b23d9e324fe5d0acbcfa70c625f2e81189046 https://git.kernel.org/stable/c/1c4f7e1177da2f229be04139c27e5370a1cfba52 https://git.kernel.org/stable/c/46f8ffd0a1f1eb6cbc94946a92c11ef601e228a1 https://git.kernel.org/stable/c/4bf5ca47203049ce3648f750a53dcdc98bcc9e3e https://git.kernel.org/stable/c/84ae3cfd7d3a63591a2eb4faa24faf678c6708aa https://git.kernel.org/stable/c/8f5b30cc12c409ff62891e47ed51e6bf0945a3ea https://git.kernel.org/stable/c/c3aee3fc1287c8a555baf3895959087cb0c33fe8 https://git.kernel.org/stable/c/c7362f6a18ed167f52f08ce25eeec8a7818c5004

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-10-18T15:15:04.988Z

Updated: 2026-10-18T15:15:04.988Z

Reserved: 2026-09-25T10:25:14.350Z

Link: CVE-2026-98455

Vulnrichment

No data.

NVD

Status : Received

Published: 2026-10-18T16:16:55.863

Modified: 2026-10-18T16:16:55.863

Link: CVE-2026-98455

Redhat

No data.

OpenCVE Enrichment

Updated: 2026-10-18T17:00:09Z

Weaknesses

CWE-476
NULL Pointer Dereference

Impact

Affected Systems

Risk and Exploitability

Tracking

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object