CVE-2026-53256: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()

1. In CISA KEV: not seen
2. Exploited (reported): not seen
3. Scanning observed: not seen
4. Proof of concept public: not seen
5. Not establishedNothing in the sources we check

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().

Exploitation

Unlikely (under 1%). EPSS under 1%, or no score yet.

CISA KEV

Not listed

Public check

No public nuclei template

Weakness

Use After Free · Memory Corruption

Vendor

Linux

Published

June 2026

Band

Unlikely (under 1%), June 2026

• Red Hat Enterprise Linux 10Fixed in kernel-6.12.0-211.53.1.el10_2 (RHSA-2026:65334)checked 15 Nov 02:00 UTC
• Red Hat Enterprise Linux 8Fixedchecked 15 Nov 02:00 UTC
• Red Hat Enterprise Linux 7Affected, no fix releasedchecked 15 Nov 02:00 UTC
• Ubuntu 26.04Fixedchecked 15 Nov 02:00 UTC
• Ubuntu 14.04Affected, no fix releasedchecked 15 Nov 02:00 UTC
• Debian 13Fixed in linux 6.12.94-1checked 15 Nov 02:00 UTC
• Debian 12Fixed in linux 6.1.176-1 (DLA-4665-1)checked 15 Nov 02:00 UTC
• SUSE Linux Enterprise Server 16.1Fixedchecked 15 Nov 02:00 UTC
• SUSE Linux Enterprise Server 16.0Fixedchecked 15 Nov 02:00 UTC
• SUSE Linux Enterprise Server 15 SP7Fixedchecked 15 Nov 02:00 UTC
• openSUSE Leap 16.0Fixedchecked 15 Nov 02:00 UTC

1. 15 Nov
   Seen in Debian’s tracker on 15 Nov: Debian 12 fixed in linux 6.1.176-1 (DLA-4665-1) Debian
2. 15 Nov
   Seen in Debian’s tracker on 15 Nov: Debian 13 fixed in linux 6.12.94-1 Debian
3. 15 Nov
   Red Hat’s tracker lists RHEL 7 as affected, with no fix released Red Hat
4. 15 Nov
   Seen in Red Hat’s tracker on 15 Nov: RHEL 8 fixed Red Hat
5. 15 Nov
   Seen in SUSE’s tracker on 15 Nov: openSUSE Leap 16.0 fixed SUSE
6. 15 Nov
   SUSE’s tracker lists SLES 15 SP1 as affected, with no fix released SUSE
7. 15 Nov
   SUSE’s tracker lists SLES 15 SP2 as affected, with no fix released SUSE
8. 15 Nov
   SUSE’s tracker lists SLES 15 SP3 as affected, with no fix released SUSE
9. 15 Nov
   Seen in SUSE’s tracker on 15 Nov: SLES 15 SP7 fixed SUSE
10. 15 Nov
    Seen in SUSE’s tracker on 15 Nov: SLES 16.0 fixed SUSE
11. 15 Nov
    Seen in SUSE’s tracker on 15 Nov: SLES 16.1 fixed SUSE
12. 15 Nov
    Ubuntu’s tracker lists Ubuntu 14.04 as affected, with no fix released Ubuntu
13. 15 Nov
    Seen in Ubuntu’s tracker on 15 Nov: Ubuntu 26.04 fixed Ubuntu
14. 15 Nov
    Ubuntu’s tracker lists Ubuntu stonking as not affected Ubuntu
15. 8 Sep
    Red Hat published RHSA-2026:65334 for RHEL 10 on 8 Sep (we saw it 15 Nov) Red Hat

• NVD entrynvd.nist.gov
• Vendor advisorygit.kernel.org
• CVE recordcve.org