CVE-2022-49828
published 2025-05-01CVE-2022-49828: In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: don't delete error page from pagecache This change is very similar to the change…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.19%
8.6th percentile
In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: don't delete error page from pagecache
This change is very similar to the change that was made for shmem [1], and
it solves the same problem but for HugeTLBFS instead.
Currently, when poison is found in a HugeTLB page, the page is removed
from the page cache. That means that attempting to map or read that
hugepage in the future will result in a new hugepage being allocated
instead of notifying the user that the page was poisoned. As [1] states,
this is effectively memory corruption.
The fix is to leave the page in the page cache. If the user attempts to
use a poisoned HugeTLB page with a syscall, the syscall will fail with
EIO, the same error code that shmem uses. For attempts to map the page,
the thread will get a BUS_MCEERR_AR SIGBUS.
[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.10-1 (bookworm) | linux 6.0.10-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 78bb920344b8a6f04b79a7c254041723b931c94f < 30571f28bb35c826219971c63bcf60d2517112ed | 30571f28bb35c826219971c63bcf60d2517112ed |
| linux | linux | >= 78bb920344b8a6f04b79a7c254041723b931c94f < ec667443b2dbc6cdbbac4073e51a17733158ec6a | ec667443b2dbc6cdbbac4073e51a17733158ec6a |
| linux | linux | >= 78bb920344b8a6f04b79a7c254041723b931c94f < 8625147cafaa9ba74713d682f5185eb62cb2aedb | 8625147cafaa9ba74713d682f5185eb62cb2aedb |
| linux | linux_kernel | < 5.15.80 | 5.15.80 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 5.16 < 6.0.10 | 6.0.10 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: hugetlbfs: don't delete error page from pagecache
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49828 [MEDIUM] CWE-755 kernel: hugetlbfs: don't delete error page from pagecache
kernel: hugetlbfs: don't delete error page from pagecache
In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: don't delete error page from pagecache
This change is very similar to the change that was made for shmem [1], and
it solves the same problem but for HugeTLBFS instead.
Currently, when poison is found in a HugeTLB page, the page is removed
from the page cache. That means that attempting to map or read that
hugepage in the future will result in a new hugepage being allocated
instead of notifying the user that the page was poisoned. As [1] states,
this is effectively memory corruption.
The fix is to leave the page in the page cache. If the user attempts to
use a poisoned HugeTLB page with a syscall, the syscall will fail with
EIO, the same error code that s
Debian
CVE-2022-49828: linux - In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: ...
vendor_debian·2022·CVSS 5.5
CVE-2022-49828 [MEDIUM] CVE-2022-49828: linux - In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: ...
In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: don't delete error page from pagecache This change is very similar to the change that was made for shmem [1], and it solves the same problem but for HugeTLBFS instead. Currently, when poison is found in a HugeTLB page, the page is removed from the page cache. That means that attempting to map or read that hugepage in the future will result in a new hugepage being allocated instead of notifying the user that the page was poisoned. As [1] states, this is effectively memory corruption. The fix is to leave the page in the page cache. If the user attempts to use a poisoned HugeTLB page with a syscall, the syscall will fail with EIO, the same error code that shmem uses. For attempts to map the page, the thread will ge
GHSA
GHSA-6cv4-fcr9-fcmw: In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: don't delete error page from pagecache
This change is very similar to
ghsa_unreviewed·2025-05-01
CVE-2022-49828 [MEDIUM] CWE-401 GHSA-6cv4-fcr9-fcmw: In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: don't delete error page from pagecache
This change is very similar to
In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: don't delete error page from pagecache
This change is very similar to the change that was made for shmem [1], and
it solves the same problem but for HugeTLBFS instead.
Currently, when poison is found in a HugeTLB page, the page is removed
from the page cache. That means that attempting to map or read that
hugepage in the future will result in a new hugepage being allocated
instead of notifying the user that the page was poisoned. As [1] states,
this is effectively memory corruption.
The fix is to leave the page in the page cache. If the user attempts to
use a poisoned HugeTLB page with a syscall, the syscall will fail with
EIO, the same error code that shmem uses. For attempts to map the page,
the thread wil
OSV
CVE-2022-49828: In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: don't delete error page from pagecache This change is very similar to t
osv·2025-05-01·CVSS 5.5
CVE-2022-49828 [MEDIUM] CVE-2022-49828: In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: don't delete error page from pagecache This change is very similar to t
In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: don't delete error page from pagecache This change is very similar to the change that was made for shmem [1], and it solves the same problem but for HugeTLBFS instead. Currently, when poison is found in a HugeTLB page, the page is removed from the page cache. That means that attempting to map or read that hugepage in the future will result in a new hugepage being allocated instead of notifying the user that the page was poisoned. As [1] states, this is effectively memory corruption. The fix is to leave the page in the page cache. If the user attempts to use a poisoned HugeTLB page with a syscall, the syscall will fail with EIO, the same error code that shmem uses. For attempts to map the page, the thread will ge
No detection rules found.
No public exploits indexed.
2025-05-01
Published