Homepage

Deadlock Affecting python3-perf6.18-debuginfo package, versions <1:6.18.16-18.222.amzn2023

Severity

 Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.01% (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-PYTHON3PERF618DEBUGINFO-16883201
  • published27 May 2026
  • disclosed8 May 2026
Report a new vulnerability Found a mistake?

Introduced: 8 May 2026

NewCVE-2026-43285  (opens in a new tab)
CWE-833  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 python3-perf6.18-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 python3-perf6.18-debuginfo package and not the python3-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:

mm/slab: do not access current->mems_allowed_seq if !allow_spin

Lockdep complains when get_from_any_partial() is called in an NMI context, because current->mems_allowed_seq is seqcount_spinlock_t and not NMI-safe:

================================ WARNING: inconsistent lock state 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N

inconsistent {INITIAL USE} -> {IN-NMI} usage. kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff889085799820 (&____s->seqcount#3){.-.-}-{0:0}, at: ___slab_alloc+0x58f/0xc00 {INITIAL USE} state was registered at: lock_acquire+0x185/0x320 kernel_init_freeable+0x391/0x1150 kernel_init+0x1f/0x220 ret_from_fork+0x736/0x8f0 ret_from_fork_asm+0x1a/0x30 irq event stamp: 56 hardirqs last enabled at (55): [<ffffffff850a68d7>] _raw_spin_unlock_irq+0x27/0x70 hardirqs last disabled at (56): [<ffffffff850858ca>] __schedule+0x2a8a/0x6630 softirqs last enabled at (0): [<ffffffff81536711>] copy_process+0x1dc1/0x6a10 softirqs last disabled at (0): [<0000000000000000>] 0x0

other info that might help us debug this: Possible unsafe locking scenario:

     CPU0
     ----
lock(&amp;____s-&gt;seqcount#3);
&lt;Interrupt&gt;
  lock(&amp;____s-&gt;seqcount#3);

*** DEADLOCK ***

According to Documentation/locking/seqlock.rst, seqcount_t is not NMI-safe and seqcount_latch_t should be used when read path can interrupt the write-side critical section. In this case, do not access current->mems_allowed_seq and avoid retry.

CVSS Base Scores

version 3.1