CVE-2026-80893 Affecting kernel6.12-tools package, versions <1:6.12.103-127.188.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-KERNEL612TOOLS-19896323
- published18 Sept 2026
- disclosed4 Sept 2026
Introduced: 4 Sep 2026
NewCVE-2026-80893 (opens in a new tab)How to fix?
Upgrade Amazon-Linux:2023 kernel6.12-tools to version 1:6.12.103-127.188.amzn2023 or higher.
This issue was patched in ALAS2023-2026-2110.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel6.12-tools package and not the kernel6.12-tools 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/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()
copy_hugetlb_page_range() clears the uffd-wp bit of migration and hwpoison entries with huge_pte_clear_uffd_wp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pte_swp_uffd_wp() and pte_swp_mkuffd_wp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages.
No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADV_HWPOISON on a 2MB anon hugetlb page shows:
offset before=120e00 offset after =120e02
The fallout is mostly latent: rmap walks match migration entries by folio range and remove_migration_pte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlb_change_protection() rewriting a writable migration entry via make_readable_migration_entry(swp_offset(entry)) -- propagates it.
Migration entries legitimately carry uffd-wp, so clear it with pte_swp_clear_uffd_wp(), matching copy_nonpresent_pte() and move_huge_pte().
A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by make_hwpoison_entry() (try_to_unmap_one() does not preserve uffd-wp on the hwpoison path) and hugetlb_change_protection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely.
References
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-80893
- https://git.kernel.org/stable/c/2b9a07002c2f296aa6a9c591213933d3492e3089
- https://git.kernel.org/stable/c/2fa11c60c9c06bafc19cf4d9efdaa36a38079e87
- https://git.kernel.org/stable/c/69cb5825d9988c7944bc9f1dc08cb233655405a7
- https://git.kernel.org/stable/c/83abe2fd5b3aeb3123b5408a5a91709c5538fb23
- https://git.kernel.org/stable/c/8b0de7005b148738d79d6c45594d566489948a68
- https://git.kernel.org/stable/c/f1b1311c0352873137768bac5a126e491271a747