CVE-2026-53154

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: restore reservation on error in hugetlb folio copy paths<br /> <br /> Two sites in mm/hugetlb.c allocate a hugetlb folio via<br /> alloc_hugetlb_folio() (consuming a VMA reservation) and then call<br /> copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c<br /> ("mm: hwpoison: support recovery from HugePage copy-on-write faults") and<br /> can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the<br /> failure path, folio_put() restores the global hugetlb pool count through<br /> free_huge_folio(), but the per-VMA reservation map entry is left marked<br /> consumed:<br /> <br /> - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY)<br /> - copy_hugetlb_page_range() fork-time CoW path when<br /> hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon<br /> folio under fork)<br /> <br /> User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the<br /> resubmission copy fails, the reservation for that address is leaked from<br /> the VMA&amp;#39;s reserve map. A subsequent fault at the same address takes the<br /> no-reservation path, and under hugetlb pool pressure the task is SIGBUSed<br /> at an address it had previously reserved. The fork-time CoW path leaks<br /> the same way in the child VMA&amp;#39;s reserve map, though it requires the much<br /> rarer combination of pinned hugetlb anon page + hwpoisoned source.<br /> <br /> Add the missing restore_reserve_on_error() call before folio_put() on both<br /> error paths.