--- cve: "CVE-2026-53154" severity: "LOW" cvss: 3.1 epss: "12%" vendor: "Linux" kev: false exploited: false published: "2026-06-25 09:16:32" tags: [cve, security, low] source: tsecurity.de CVE-Dossier exported: "2026-09-07T10:38:36+02:00" --- # CVE-2026-53154 > 3.1 LOW ## Beschreibung In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths. ## Patch verfügbar (OSV) - Kernel ≥ 6.6.143 - Kernel ≥ 6.12.94 - Kernel ≥ 6.18.36 - Kernel ≥ 7.0.13 ## Referenzen - - - - - --- _Exportiert aus dem [tsecurity.de CVE-Dossier](https://tsecurity.de/cve?cve=CVE-2026-53154) · Datenquellen: EUVD (ENISA), NVD, OSV, CISA KEV, FIRST EPSS, Exploit-DB, BSI BITS_