Improper Resource Locking Affecting kernel-tools-debuginfo package, versions <1:6.1.168-202.320.amzn2023
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-AMZN2023-KERNELTOOLSDEBUGINFO-16625520
- published10 May 2026
- disclosed25 Mar 2026
Introduced: 25 Mar 2026
CVE-2026-23356 (opens in a new tab)How to fix?
Upgrade Amazon-Linux:2023 kernel-tools-debuginfo to version 1:6.1.168-202.320.amzn2023 or higher.
This issue was patched in ALAS2023-2026-1681.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-tools-debuginfo package and not the kernel-tools-debuginfo package as distributed by Amazon-Linux.
See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()
Even though we check that we "should" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing.
If that happened, we logged "LOGIC BUG for enr=...", but still did not return an error.
The rest of the code now assumed that this request has references for the relevant activity log extents.
The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case.
Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put().
Fix:
Do not crash the kernel for a condition that is harmless during normal operation: also catch "e->refcnt == 0", not only "e == NULL" when being noisy about "al_complete_io() called on inactive extent %u\n".
And do not try to be smart and "guess" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible "partially in activity log" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock().
A latter call for the same request will then resume from where we left off.
References
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-23356
- https://git.kernel.org/stable/c/7752569fc78e89794ce28946529850282233f99d
- https://git.kernel.org/stable/c/933d161baa3794547adee621c0bf52cbf2c1b3cd
- https://git.kernel.org/stable/c/ab140365fb62c0bdab22b2f516aff563b2559e3b
- https://git.kernel.org/stable/c/cf01aa6288e1190f89865e765056e2a9d8190639
- https://git.kernel.org/stable/c/d1ef3aed4df2ef1fe46befd8f2da9a6ec5445508
- https://git.kernel.org/stable/c/e91d8d6565b7819d13dab21d4dbed5b45efba59b
- https://git.kernel.org/stable/c/eef1390125b660b8b61f9f227a03bb9c5e6d36a5
- https://git.kernel.org/stable/c/f558e5404a72054b525dced1a0c66aa95a144153