Vulnerability · CVE-2024-50044
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts…
Published Oct 21, 2024 · catalog updated Oct 15, 2026 · linux kernel
Check if you run it
No confirmed exploitation is on record for CVE-2024-50044. EPSS is 0.19%. Act only if a listed version of linux kernel is installed.
Gaps on this record
- No vendor fix or required action is stored. Compare the linked advisory before you change production.
- Severity
- Low3.3
- Known exploitation
- Not in CISA/VulnCheck KEV
- EPSS
- 0.19%
- Remediation
- Advisory link
- Affected products
- cpe linux/linux kernel
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
Are you affected?
Enter the version you run. The result uses only the ranges stored on this record.
The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.
- cpe linux/linux kernel6.12
How to fix CVE-2024-50044
Recommended remediation
A patch or advisory reference is linked. Open the original publisher for availability by product version.
Official advisories
What to do
Three questions, each answered from this record only. Confirm the vendor advisory before you patch.
Should you patch?
No confirmed exploitation is on record for CVE-2024-50044. EPSS is 0.19%. Act only if a listed version of linux kernel is installed.
Which versions are affected?
Compare what you have installed with linux/linux kernel 6.12. Compare the installed version with the linked vendor advisory before you change production.
What should an analyst verify?
CWE-667. EPSS 0.19%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.
Code
The project this record applies to. Exploit listings stay in References.
Timeline
Detection, updates, and resolution for this record.
Oct 21, 2024 · NIST NVD
Detected
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking depende
Oct 15, 2026 · NIST NVD
Updated
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking depende
Sources
- CVE.orgVulnerability recordCVE-2024-50044
Official CVE identifier
cve.org - FIRST EPSSExploitation probabilityCVE-2024-50044
30-day exploitation probability 0.19%
first.org - NIST NVDVulnerability recordCVE-2024-50044
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it caus
nvd.nist.gov
References
Freshness
Last verified in this catalog Oct 21, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.