In the Linux kernel, the following vulnerability has been resolved:
mm: hugetlb: independent PMD page table shared count
The folio refcount may be increased unexpectly through try_get_folio() by
caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount
to check whether a pmd page table is shared. The check is incorrect if
the refcount is increased by the above caller, and this can cause the page
table leaked:
BUG: Bad page state in process sh pfn:109324
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324
flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)
page_type: f2(table)
raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000
raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000
page dumped because: nonzero mapcount
...
CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7
Tainted: [B]=BAD_PAGE
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
Call trace:
show_stack+0x20/0x38 (C)
dump_stack_lvl+0x80/0xf8
dump_stack+0x18/0x28
bad_page+0x8c/0x130
free_page_is_bad_report+0xa4/0xb0
free_unref_page+0x3cc/0x620
__folio_put+0xf4/0x158
split_huge_pages_all+0x1e0/0x3e8
split_huge_pages_write+0x25c/0x2d8
full_proxy_write+0x64/0xd8
vfs_write+0xcc/0x280
ksys_write+0x70/0x110
__arm64_sys_write+0x24/0x38
invoke_syscall+0x50/0x120
el0_svc_common.constprop.0+0xc8/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x34/0x128
el0t_64_sync_handler+0xc8/0xd0
el0t_64_sync+0x190/0x198
The issue may be triggered by damon, offline_page, page_idle, etc, which
will increase the refcount of page table.
1. The page table itself will be discarded after reporting the
"nonzero mapcount".
2. The HugeTLB page mapped by the page table miss freeing since we
treat the page table as shared and a shared page table will not be
unmapped.
Fix it by introducing independent PMD page table shared count. As
described by comment, pt_index/pt_mm/pt_frag_refcount are used for s390
gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv
pmds, so we can reuse the field as pt_share_count.
Security readout for executives and security teams
Plain-English summary
CVE-2024-57883 is a Linux kernel memory-management flaw affecting HugeTLB page tables. Incorrectly treating a page table as shared can leak page-table and huge-page resources and produce a bad-page state. The assigned CVSS score is 7.8, reflecting potentially serious local impact.
Executive priority
Treat as a high-priority kernel maintenance issue, especially on shared Linux hosts or systems using huge pages. Schedule vendor-approved updates promptly. Emergency response is not supported by the supplied exploitation evidence, but vulnerable kernels should not remain indefinitely exposed.
Technical view
The kernel used a folio reference count to determine whether a PMD page table was shared. Other kernel operations can independently increase that count, causing huge_pmd_unshare() to misclassify the table. This can prevent proper unmapping and freeing. The fix introduces a separate PMD page-table share counter for affected architectures.
Likely exposure
Exposure applies to affected Linux kernel builds where HugeTLB mappings and relevant memory-management operations are used. The supplied affected-version data spans several kernel lines but is not sufficiently precise for distribution packages; verify the exact running kernel against vendor advisories and the listed stable fixes.
Exploitation context
The CVSS vector describes a local, low-complexity issue requiring low privileges and no user interaction. The source bundle does not establish public exploitation, exploit availability, or inclusion in CISA KEV. Known triggering contexts include DAMON, page offlining, page-idle handling, and huge-page splitting.
Researcher notes
The demonstrated failure is incorrect lifetime accounting: transient folio references contaminate the sharing decision, leading to leaked page-table and HugeTLB resources. The separate pt_share_count removes that ambiguity. The supplied sources do not demonstrate a reliable path from this corruption state to confidentiality or integrity compromise, despite the CVSS vector assigning high impacts.
Mitigation direction
Install a vendor-supported kernel containing the applicable stable fix.
Check distribution advisories for the corrected package version for each deployed kernel line.
Prioritize multi-user or untrusted-workload systems using HugeTLB or affected memory-management features.
Reboot into the corrected kernel and remove vulnerable kernels from normal boot selection.
Validation and detection
Record each system's running kernel version and distribution package release.
Compare kernel source or vendor changelog against the applicable listed stable fix.
Confirm systems rebooted successfully and are running the corrected kernel.
Review kernel logs for bad-page reports, nonzero mapcount messages, or related memory-management faults.
Verify HugeTLB usage and relevant features to refine exposure; absence of logs does not prove safety.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-57883 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
9Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.