Homepage

Time-of-check Time-of-use (TOCTOU) Affecting perf6.18-debuginfo package, versions <1:6.18.35-68.127.amzn2023

Severity

 Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.13% (3rd percentile)

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-PERF618DEBUGINFO-18525068
  • published5 Aug 2026
  • disclosed19 Jul 2026
Report a new vulnerability Found a mistake?

Introduced: 19 Jul 2026

NewCVE-2026-64112  (opens in a new tab)
CWE-367  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 perf6.18-debuginfo to version 1:6.18.35-68.127.amzn2023 or higher.
This issue was patched in ALAS2023-2026-1881.

NVD Description

Note: Versions mentioned in the description apply only to the upstream perf6.18-debuginfo package and not the perf6.18-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:

rbd: eliminate a race in lock_dwork draining on unmap

Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation.

A more problematic example is maybe_kick_acquire():

if (have_requests || delayed_work_pending(&amp;rbd_dev-&gt;lock_dwork)) {
        dout(&#34;%s rbd_dev %p kicking lock_dwork\n&#34;, __func__, rbd_dev);
        mod_delayed_work(rbd_dev-&gt;task_wq, &amp;rbd_dev-&gt;lock_dwork, 0);
}

It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race.

When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated

rbd_assert(rbd_image_format_valid(rbd_dev-&gt;image_format));

in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action().

Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().

CVSS Base Scores

version 3.1