PT-2026-52250 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53154
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux