Linux Kernel: security vulnerability (CVE-2026-80893)

What is affected, what to do

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.

Update Linux Kernel to version 6.1.183, Linux Kernel to version 6.6.151, Linux Kernel to version 6.12.103.

Affected

• Linux Kernel lt 5.19..6.1.183
• Linux Kernel lt 6.2..6.6.151
• Linux Kernel lt 6.7..6.12.103
• Linux Kernel lt 6.13..6.18.44
• Linux Kernel lt 6.19..7.1.8

Fixed in

• Linux Kernel 6.1.183
• Linux Kernel 6.6.151
• Linux Kernel 6.12.103
• Linux Kernel 6.18.44
• Linux Kernel 7.1.8
• Linux Kernel 7.2

Not sure whether and how you are affected? Ask a question about this vulnerability

Metrics

Detection rules

No NEOSEC detection rule is available for this vulnerability yet.

Classification under NIS2 and CRA

Rule-based classification from exploitation status and severity. It does not replace a case-by-case assessment.

NIS2

NIS2 is EU Directive (EU) 2022/2555 to raise the level of cybersecurity across the Union. It substantially broadens obligations compared with the first NIS directive: more sectors, mandatory risk management, staged reporting duties and personal accountability of senior management.

Read in glossary

Handle the vulnerability in regular vulnerability handling under Art. 21(2)(e) NIS2.

CRA

The CRA is EU Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for „products with digital elements“ — from industrial controllers and software to connected consumer devices. For the first time manufacturers must ensure security across the entire product lifecycle, handle vulnerabilities and provide security updates.

Read in glossary

From 11.12.2027, Annex I Part II CRA requires manufacturers of affected products with digital elements to handle vulnerabilities without delay and provide security updates.

ISO/IEC 27001

ISO/IEC 27001 is the internationally leading standard for an information security management system (ISMS). It describes a risk-based, process-oriented framework to systematically plan, implement, review and improve information security.

Read in glossary

Control A.8.8, management of technical vulnerabilities: assess relevance to your systems, plan remediation and keep evidence.

Description

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.

Source: HKCERT (CC BY 3.0 HK) · HKCERT rating: medium, Ubuntu Security Notices, Debian LTS Advisories, suse_csaf, BSI WID Portal, BSI CSAF, ENISA EUVD, Microsoft Security Update Guide, cvelistv5, NVD (NIST), CVE.org (MITRE)

Vendors and products

• Debian Linux
• Debian Linux-6.12
• Linux Linux
• Red Hat Openshift
• Ubuntu Ubuntu Linux
• Ubuntu Linux-aws
• Ubuntu Linux-aws-6.8
• Ubuntu Linux-aws-7.0
• Ubuntu Linux-aws-fips
• Ubuntu Linux-azure
• Ubuntu Linux-azure-6.8
• Ubuntu Linux-azure-fde

References & sources

• git.kernel.orgstable/c/f1b1311c0352873137768bac5a126e491271a747euvd
• git.kernel.orgstable/c/69cb5825d9988c7944bc9f1dc08cb233655405a7euvd
• git.kernel.orgstable/c/8b0de7005b148738d79d6c45594d566489948a68euvd
• git.kernel.orgstable/c/2b9a07002c2f296aa6a9c591213933d3492e3089euvd
• git.kernel.orgstable/c/2fa11c60c9c06bafc19cf4d9efdaa36a38079e87euvd
• git.kernel.orgstable/c/83abe2fd5b3aeb3123b5408a5a91709c5538fb23euvd

Changes to this CVE

Who changed this CVE and when: NVD (analysis, affected products, CVSS), the CVE publisher (CNA) and additional providers such as CISA (ADP).

1. 06.11.2026Record modifiedCISA ADP

   CISA assessment (SSVC): exploitation: none known, automatable: no

   Show the original change

   Individual changes of this event as published by NVD

   Type	Action	Before	After
   SSVC assessment	added	—	{"id":"CVE-2026-80893","role":"CISA Coordinator","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"partial"}],"version":"2.0.3","timestamp":"2026-11-06T17:04:44.937840Z"}

   Source identifier: 134c704f-9b21-4f2e-91b3-4a467353bcc0

2. 04.09.2026ReceivedLinux

   Description added or changed

   New references:

   • 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

   and 2 more references

   Show 8 original changes

   Individual changes of this event as published by NVD

   Type	Action	Before	After
   Description	added	—	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.
   Affected versions (publisher)	added	—	New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/80xxx/CVE-2026-80893.json">CVE-2026-80893</a>
   Reference	added	—	https://git.kernel.org/stable/c/2b9a07002c2f296aa6a9c591213933d3492e3089
   Reference	added	—	https://git.kernel.org/stable/c/2fa11c60c9c06bafc19cf4d9efdaa36a38079e87
   Reference	added	—	https://git.kernel.org/stable/c/69cb5825d9988c7944bc9f1dc08cb233655405a7
   Reference	added	—	https://git.kernel.org/stable/c/83abe2fd5b3aeb3123b5408a5a91709c5538fb23
   Reference	added	—	https://git.kernel.org/stable/c/8b0de7005b148738d79d6c45594d566489948a68
   Reference	added	—	https://git.kernel.org/stable/c/f1b1311c0352873137768bac5a126e491271a747

   Source identifier: 416baaa9-dc9f-4396-8d5f-8c081fb06d67