Homepage

Use of Blocking Code in Single-threaded, Non-blocking Context Affecting kernel6.18-libbpf-debuginfo package, versions <1:6.18.16-18.222.amzn2023

Severity

 Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.44% (35th 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-KERNEL618LIBBPFDEBUGINFO-16883142
  • published27 May 2026
  • disclosed6 May 2026
Report a new vulnerability Found a mistake?

Introduced: 6 May 2026

CVE-2026-43245  (opens in a new tab)
CWE-1322  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 kernel6.18-libbpf-debuginfo to version 1:6.18.16-18.222.amzn2023 or higher.
This issue was patched in ALAS2023-2026-1702.

NVD Description

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

ntfs: ->d_compare() must not block

... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now.

Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX.