Описание
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.
Отчет
This flaw is rated as a Moderate severity impact because exploitation requires a local attacker to win a precise timing race between hugetlb page table unsharing and fast page lookup operations. While an attacker could potentially access memory tables associated with another process, the vulnerability requires shared huge page mappings to be actively utilized on the system. The issue cannot be exploited remotely and does not directly lead to kernel code execution.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Will not fix | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Will not fix | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat Enterprise Linux 10 | kernel | Fixed | RHSA-2025:13598 | 11.08.2025 |
| Red Hat Enterprise Linux 8 | kernel-rt | Fixed | RHSA-2025:13590 | 11.08.2025 |
| Red Hat Enterprise Linux 8 | kernel | Fixed | RHSA-2025:13589 | 11.08.2025 |
| Red Hat Enterprise Linux 8.2 Advanced Update Support | kernel | Fixed | RHSA-2025:21667 | 18.11.2025 |
| Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support | kernel | Fixed | RHSA-2025:15660 | 11.09.2025 |
| Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On | kernel | Fixed | RHSA-2025:15660 | 11.09.2025 |
Показывать по
Дополнительная информация
Статус:
7.1 High
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.
In the Linux kernel, the following vulnerability has been resolved: m ...
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.
7.1 High
CVSS3