Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

redhat логотип

CVE-2026-98373

Опубликовано: 07 окт. 2026
Источник: redhat
CVSS3: 4.7
EPSS Низкий

Описание

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: preserve mremap address delta when skipping page tables move_hugetlb_page_tables() optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist, either initially or after unsharing a PMD table. The common loop increment then steps to the first entry in the next page table. However, the code advances both the source and destination addresses to the last entries in their respective page tables, which is wrong. The destination address must be advanced only by the same amount as the source address. If the source and destination offsets within their page tables differ, the destination address can be advanced too far, causing follow-up issues. Fix this by advancing the destination address by the source advance distance. With a reproducer, we were able to trigger a kernel panic on x86-64. With this fix in place, we can no longer reproduce the issue.

A flaw was found in the Linux kernel's HugeTLB (huge memory page) subsystem. A local attacker can exploit this vulnerability to cause a Denial of Service (DoS) by triggering a system crash. The issue occurs during memory remapping operations when the kernel incorrectly calculates destination addresses while skipping unmapped page tables, leading to memory management errors and a kernel panic.

Отчет

A logic error in move_hugetlb_page_tables can advance the destination address by a different offset than the source address when mremap skips an absent source page table entry or handles huge_pmd_unshare. If the source and destination offsets within their page tables differ, later page table operations can use an incorrect destination address. A reproducer reported a kernel panic on x86-64, resulting in local denial of service. For the CVSS the PR:L rating reflects that a local process must create and manipulate suitable hugetlb mappings through mremap. Reliable triggering also requires a specific hugepage mapping layout and page table state, so AC:H is appropriate.

Меры по смягчению последствий

Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.

Затронутые пакеты

ПлатформаПакетСостояниеРекомендацияРелиз
Red Hat Enterprise Linux 10kernelAffected
Red Hat Enterprise Linux 6kernelOut of support scope
Red Hat Enterprise Linux 7kernelNot affected
Red Hat Enterprise Linux 7kernel-rtNot affected
Red Hat Enterprise Linux 8kernelNot affected
Red Hat Enterprise Linux 8kernel-rtNot affected
Red Hat Enterprise Linux 9kernelAffected
Red Hat Enterprise Linux 9kernel-rtNot affected
Red Hat OpenShift Container Platform 4openshift/ose-rhel-coreos-8Not affected
Red Hat OpenShift Container Platform 4openshift/ose-rhel-coreos-9Affected

Показывать по

Дополнительная информация

Статус:

Moderate
Дефект:
CWE-20
https://bugzilla.redhat.com/show_bug.cgi?id=2547432kernel: mm/hugetlb: preserve mremap address delta when skipping page tables

EPSS

Процентиль: 5%
0.00161
Низкий

4.7 Medium

CVSS3

Связанные уязвимости

ubuntu
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: preserve mremap address delta when skipping page tables move_hugetlb_page_tables() optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist, either initially or after unsharing a PMD table. The common loop increment then steps to the first entry in the next page table. However, the code advances both the source and destination addresses to the last entries in their respective page tables, which is wrong. The destination address must be advanced only by the same amount as the source address. If the source and destination offsets within their page tables differ, the destination address can be advanced too far, causing follow-up issues. Fix this by advancing the destination address by the source advance distance. With a reproducer, we were able to trigger a kernel panic on x86-64. With this fix in place, we can no longer reproduce the issue.

nvd
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: preserve mremap address delta when skipping page tables move_hugetlb_page_tables() optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist, either initially or after unsharing a PMD table. The common loop increment then steps to the first entry in the next page table. However, the code advances both the source and destination addresses to the last entries in their respective page tables, which is wrong. The destination address must be advanced only by the same amount as the source address. If the source and destination offsets within their page tables differ, the destination address can be advanced too far, causing follow-up issues. Fix this by advancing the destination address by the source advance distance. With a reproducer, we were able to trigger a kernel panic on x86-64. With this fix in place, we can no longer reproduce the issue.

debian
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: m ...

github
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: preserve mremap address delta when skipping page tables move_hugetlb_page_tables() optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist, either initially or after unsharing a PMD table. The common loop increment then steps to the first entry in the next page table. However, the code advances both the source and destination addresses to the last entries in their respective page tables, which is wrong. The destination address must be advanced only by the same amount as the source address. If the source and destination offsets within their page tables differ, the destination address can be advanced too far, causing follow-up issues. Fix this by advancing the destination address by the source advance distance. With a reproducer, we were able to trigger a kernel panic on x86-64. With this fix in place, we can no longer reproduce the issue.

oracle-oval
7 дней назад

ELSA-2026-500572: Unbreakable Enterprise kernel security update (IMPORTANT)

EPSS

Процентиль: 5%
0.00161
Низкий

4.7 Medium

CVSS3