CVE-2026-98293

A flaw was found in the Linux kernel's Bluetooth subsystem. This flaw allows a local user or adjacent attacker to cause a Denial of Service (DoS) by triggering a resource leak. When handling Bluetooth Isochronous (ISO) connections, the kernel fails to release a reference to the parent socket if child socket allocation fails. Over time, repeated failures cause kernel memory to remain allocated, potentially leading to system resource exhaustion.

A moderate severity flaw in the Linux kernel's Bluetooth ISO (Isochronous) connection handling affects Red Hat Enterprise Linux 9 (9.6 and later), Red Hat Enterprise Linux 10, Red Hat In-Vehicle OS 2, and OpenShift Container Platform releases built on RHEL 9 CoreOS (4.19 and later). When an ISO connection becomes ready, iso_conn_ready() takes a reference on the parent socket via iso_get_sock(); if the subsequent child socket allocation (iso_sock_alloc()) fails, the error path releases the socket lock but never drops that reference with sock_put(), leaking the parent socket and its associated kernel memory. A local user or an adjacent Bluetooth peer can trigger this path, and repeated failures accumulate leaked kernel memory, potentially leading to resource exhaustion and a denial of service. Red Hat rates this flaw Moderate (CVSS 3.1 score 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Practical exploitability is limited: triggering the leak requires a GFP_ATOMIC child socket allocation failure under memory pressure, which an attacker cannot reliably control, and the demonstrated impact is limited resource retention rather than reliable system-wide exhaustion; for this reason the severity was reconciled down from an initial automated HIGH estimate. Older Red Hat Enterprise Linux 6, 7, and 8 streams, RHEL 9.2 and 9.4, their kernel-rt counterparts, and OpenShift releases based on RHEL 8 CoreOS are not affected because the code that introduced this flaw is not present in those kernels. The fix for the affected streams is deferred and will be delivered in a future planned update; the residual risk is gradual kernel memory consumption on systems where Bluetooth ISO connections are repeatedly established while child socket allocation fails, which over time could degrade system availability.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

This flaw is reachable only through the Bluetooth subsystem, so systems that do not require Bluetooth can mitigate it by disabling Bluetooth. To unload Bluetooth until the next reboot, run as root:

modprobe -r bluetooth

To prevent the Bluetooth module from being loaded at boot time, create /etc/modprobe.d/disable-bluetooth.conf containing: blacklist bluetooth Bluetooth may also be disabled in the system firmware/BIOS settings where supported. Systems that require Bluetooth functionality have no mitigation other than applying a kernel that contains the fix once it is released for their stream.