Linux: Concurrent Execution using Shared Resource with Improper Synchronization
CVE-2026-45942 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 a3a7d360252c0d84ae8bda067fb296c9e82928d3, 57e83bfbe1e412ac42daced2086f3c6f9a17bba0, c05033cfc5c7699cd4df8d48cef94d01da755f24 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.13% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to a3a7d360252c0d84ae8bda067fb296c9e82928d3 or 57e83bfbe1e412ac42daced2086f3c6f9a17bba0 or c05033cfc5c7699cd4df8d48cef94d01da755f24 or 29a07d691d282faf38c33d4b61839b89399110f9, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.6.130 or 6.12.75 or 6.18.14 or 6.19.4, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | c9de560ded61faa5b754137b7753da252391c55a up to, but not including, a3a7d360252c0d84ae8bda067fb296c9e82928d3; c9de560ded61faa5b754137b7753da252391c55a up to, but not including, 57e83bfbe1e412ac42daced2086f3c6f9a17bba0; c9de560ded61faa5b754137b7753da252391c55a up to, but not including, c05033cfc5c7699cd4df8d48cef94d01da755f24; c9de560ded61faa5b754137b7753da252391c55a up to, but not including, 29a07d691d282faf38c33d4b61839b89399110f9; c9de560ded61faa5b754137b7753da252391c55a up to, but not including, f29709a7a3fc38f5015d850504762cdef0e151f9; c9de560ded61faa5b754137b7753da252391c55a up to, but not including, bdc56a9c46b2a99c12313122b9352b619a2e719e; 2.6.25 | a3a7d360252c0d84ae8bda067fb296c9e82928d3, 57e83bfbe1e412ac42daced2086f3c6f9a17bba0, c05033cfc5c7699cd4df8d48cef94d01da755f24, 29a07d691d282faf38c33d4b61839b89399110f9, f29709a7a3fc38f5015d850504762cdef0e151f9, bdc56a9c46b2a99c12313122b9352b619a2e719e |
| Linux | Linux Kernel | 2.6.25 up to, but not including, 6.6.130; 6.7 up to, but not including, 6.12.75; 6.13 up to, but not including, 6.18.14; 6.19 up to, but not including, 6.19.4 | 6.6.130, 6.12.75, 6.18.14, 6.19.4 |
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: ext4: fix e4b bitmap inconsistency reports A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report: ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock.
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).
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
- git.kernel.org/stable/c/29a07d691d282faf38c33d4b61839b89399110f9
- git.kernel.org/stable/c/57e83bfbe1e412ac42daced2086f3c6f9a17bba0
- git.kernel.org/stable/c/bdc56a9c46b2a99c12313122b9352b619a2e719e
- git.kernel.org/stable/c/c05033cfc5c7699cd4df8d48cef94d01da755f24
- git.kernel.org/stable/c/f29709a7a3fc38f5015d850504762cdef0e151f9
Other references
Recent Concurrent Execution using Shared Resource with Improper Synchronization vulnerabilities
- 7.5 High severity
- 7.8 High severity
- 8.8 High severity
- 7.5 High severity
- 7.8 High severity
- 7.8 High severity
Spotted an error? Tell us.