Homepage

CVE-2026-90400 Affecting bpftool6.12-debuginfo package, versions <1:6.12.110-135.201.amzn2023

Severity

 Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.17% (6th 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-BPFTOOL612DEBUGINFO-20863502
  • published13 Oct 2026
  • disclosed17 Sept 2026
Report a new vulnerability Found a mistake?

Introduced: 17 Sep 2026

CVE-2026-90400  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 bpftool6.12-debuginfo to version 1:6.12.110-135.201.amzn2023 or higher.
This issue was patched in ALAS2023-2026-3196.

NVD Description

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

md: recheck spare changes before starting sync

remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended.

md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them.

The race can occur as follows:

raid10d Worker Normal IO

                                         raid10_write_request()
                                         wait_blocked_dev()

set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true

             raid10_remove_disk()
             rdev = replacement
             replacement = NULL
                                         rdev_dec_pending(NULL)
             unlock mddev                (NULL)-&gt;nr_pending--

In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending.

Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing.