CyberSecBulletin
CVE-2026-46275NVD status: Modified

Linux: Concurrent Execution using Shared Resource with Improper Synchronization

Published Updated By the CyberSecBulletin desk

CVE-2026-46275 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 78aad93e938f013d9272fe0ee168f27883afa95c, e2d19969c8d9198ecc3090bcd5312ecd503a3339, c85cff648a2bc92322912db5f1727ad05afae7b6 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.23% 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 78aad93e938f013d9272fe0ee168f27883afa95c or e2d19969c8d9198ecc3090bcd5312ecd503a3339 or c85cff648a2bc92322912db5f1727ad05afae7b6 or 9d20d48be2c4a071fb015eb09bda2cecd25daf34, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 4.15 or 4.20 or 5.5 or 5.9, whichever matches your release line, or a later version.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux3b799254cf6f481460719023d7a18f46651e5e7f up to, but not including, 78aad93e938f013d9272fe0ee168f27883afa95c; 3b799254cf6f481460719023d7a18f46651e5e7f up to, but not including, e2d19969c8d9198ecc3090bcd5312ecd503a3339; 3b799254cf6f481460719023d7a18f46651e5e7f up to, but not including, c85cff648a2bc92322912db5f1727ad05afae7b6; 3b799254cf6f481460719023d7a18f46651e5e7f up to, but not including, 9d20d48be2c4a071fb015eb09bda2cecd25daf34; 3b799254cf6f481460719023d7a18f46651e5e7f up to, but not including, 81c7a3c22a0f2808cf4ae0b4908f59763b23606d; 3b799254cf6f481460719023d7a18f46651e5e7f up to, but not including, 192cb0f1ca706d9a1bc36ae0ad5f666d1e4fd894; 3b799254cf6f481460719023d7a18f46651e5e7f up to, but not including, 7338031946bd06f6dff149e67b60c4cd083bfea8; 3b799254cf6f481460719023d7a18f46651e5e7f up to, but not including, c1bb9336ae6b54a5f6a353c4bd4ed9a4307e429b; and 11 more ranges78aad93e938f013d9272fe0ee168f27883afa95c, e2d19969c8d9198ecc3090bcd5312ecd503a3339, c85cff648a2bc92322912db5f1727ad05afae7b6, 9d20d48be2c4a071fb015eb09bda2cecd25daf34, 81c7a3c22a0f2808cf4ae0b4908f59763b23606d, 192cb0f1ca706d9a1bc36ae0ad5f666d1e4fd894
SiemensSIMATIC S7-1500 TM MFP - GNU/Linux subsystemall versionsNot stated
LinuxLinux Kernel4.14.203 up to, but not including, 4.15; 4.19.153 up to, but not including, 4.20; 5.4.73 up to, but not including, 5.5; 5.8.17 up to, but not including, 5.9; 5.9.2 up to, but not including, 5.10.258; 5.11 up to, but not including, 5.15.209; 5.16 up to, but not including, 6.1.175; 6.2 up to, but not including, 6.6.142; and 4 more ranges4.15, 4.20, 5.5, 5.9, 5.10.258, 5.15.209

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: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.

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.