CyberSecBulletin
CVE-2026-43023NVD status: Modified

Linux: Concurrent Execution using Shared Resource with Improper Synchronization

Published Updated By the CyberSecBulletin desk

CVE-2026-43023 is a high-severity concurrent execution using shared resource with improper synchronization vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions dabf22269242e2f2bf44c43fcdc2fa763df7f9cc, adb90cd0f9f7a8d438fcb93354040fbafc5ae2a0, 7e296ffdab5bdab718dff7c14288fdcb9154fa27 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.1% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to dabf22269242e2f2bf44c43fcdc2fa763df7f9cc or adb90cd0f9f7a8d438fcb93354040fbafc5ae2a0 or 7e296ffdab5bdab718dff7c14288fdcb9154fa27 or 98c8d3bfdaa657d8f472dbbebd7ea8cd816d8a8d, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 6.1.168 or 6.6.134 or 6.12.81 or 6.18.22, whichever matches your release line, or a later version.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux70a13b1e25fef37c87c8a1228ddb8900efbca7cf up to, but not including, dabf22269242e2f2bf44c43fcdc2fa763df7f9cc; 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 up to, but not including, adb90cd0f9f7a8d438fcb93354040fbafc5ae2a0; 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 up to, but not including, 7e296ffdab5bdab718dff7c14288fdcb9154fa27; 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 up to, but not including, 98c8d3bfdaa657d8f472dbbebd7ea8cd816d8a8d; 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 up to, but not including, d002bd11024bd231bcb606877e33951ffb7bed14; 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 up to, but not including, 8a5b0135d4a5d9683203a3d9a12a711ccec5936b; 6.1.109 up to, but not including, 6.1.168; 6.3dabf22269242e2f2bf44c43fcdc2fa763df7f9cc, adb90cd0f9f7a8d438fcb93354040fbafc5ae2a0, 7e296ffdab5bdab718dff7c14288fdcb9154fa27, 98c8d3bfdaa657d8f472dbbebd7ea8cd816d8a8d, d002bd11024bd231bcb606877e33951ffb7bed14, 8a5b0135d4a5d9683203a3d9a12a711ccec5936b
LinuxLinux Kernel6.1.109 up to, but not including, 6.1.168; 6.3.1 up to, but not including, 6.6.134; 6.7 up to, but not including, 6.12.81; 6.13 up to, but not including, 6.18.22; 6.19 up to, but not including, 6.19.12; 6.3; 7.06.1.168, 6.6.134, 6.12.81, 6.18.22, 6.19.12

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
LocalThe attacker needs local access or must trick a user into running something.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
LowA basic user account is enough.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

Official description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: fix race conditions in sco_sock_connect() sco_sock_connect() checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter sco_connect(), leading to use-after-free. The buggy scenario involves three participants and was confirmed with additional logging instrumentation: Thread A (connect): HCI disconnect: Thread B (connect): sco_sock_connect(sk) sco_sock_connect(sk) sk_state==BT_OPEN sk_state==BT_OPEN (pass, no lock) (pass, no lock) sco_connect(sk): sco_connect(sk): hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock(sk) sco_chan_add: conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del: lock_sock(sk) sco_chan_del: sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock (unblocked) hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock(sk) sco_chan_add: sk->conn=conn2 sk_state= BT_CONNECT // zombie sk! release_sock hci_dev_unlock Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers double sock_put() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when sco_conn_del() cleared the association. Fix this by: - Moving lock_sock() before the sk_state/sk_type checks in sco_sock_connect() to serialize concurrent connect attempts - Fixing the sk_type != SOCK_SEQPACKET check to actually return the error instead of just assigning it - Adding a state re-check in sco_connect() after lock_sock() to catch state changes during the window between the locks - Adding sco_pi(sk)->conn check in sco_chan_add() to prevent double-attach of a socket to multiple connections - Adding hci_conn_drop() on sco_chan_add failure to prevent HCI connection leaks

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Concurrent Execution using Shared Resource with Improper Synchronization

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

How developers prevent this class of flaw

  • In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
  • Use thread-safe capabilities such as the data access abstraction in Spring.
  • Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

More Concurrent Execution using Shared Resource with Improper Synchronization vulnerabilities (CWE-362)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Concurrent Execution using Shared Resource with Improper Synchronization vulnerabilities

Spotted an error? Tell us.