NULL Pointer Dereference Affecting python3-perf6.12-debuginfo package, versions <1:6.12.111-136.204.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-PYTHON3PERF612DEBUGINFO-20859792
- published13 Oct 2026
- disclosed24 Sept 2026
Introduced: 24 Sep 2026
NewCVE-2026-97416 (opens in a new tab)How to fix?
Upgrade Amazon-Linux:2023 python3-perf6.12-debuginfo to version 1:6.12.111-136.204.amzn2023 or higher.
This issue was patched in ALAS2023-2026-3193.
NVD Description
Note: Versions mentioned in the description apply only to the upstream python3-perf6.12-debuginfo package and not the python3-perf6.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:
btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk()
[BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache:
KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ...
[CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache:
cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */
A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL.
The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel.
[FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.
References
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-97416
- https://git.kernel.org/stable/c/18d32b0013efba19f7ad3e5b08d7aee813d604a6
- https://git.kernel.org/stable/c/59f75e0c8724d4adebc08c7dd3ff2358b80c21f7
- https://git.kernel.org/stable/c/9740dd0c17a4be8cc47a06c5ca5293471a7e286e
- https://git.kernel.org/stable/c/322f891b4d4fe64acb3351a0ffa62a7fa5ba7256
- https://git.kernel.org/stable/c/81a664ed8b1a44c76b204c4bd0d751317a02c5cd
- https://git.kernel.org/stable/c/9f37a6d6ae9e998232e2ba091ab4999cdf967e1b
- https://git.kernel.org/stable/c/e479236a8f4d85c4fb6b3f7c2556c21f583e2bf2