CVE-2024-51729 (GCVE-0-2024-51729)
Vulnerability from cvelistv5
Published
2025-01-11 12:35
Modified
2026-08-05 11:43
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
mm: use aligned address in copy_user_gigantic_page()
In current kernel, hugetlb_wp() calls copy_user_large_folio() with the
fault address. Where the fault address may be not aligned with the huge
page size. Then, copy_user_large_folio() may call
copy_user_gigantic_page() with the address, while
copy_user_gigantic_page() requires the address to be huge page size
aligned. So, this may cause memory corruption or information leak,
addtional, use more obvious naming 'addr_hint' instead of 'addr' for
copy_user_gigantic_page().
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/hugetlb.c",
"mm/memory.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "cb12d61361ce769672c7c7bd32107252598cdd8b",
"status": "affected",
"version": "530dd9926dc16220d2fae0997f45cda94f5f0864",
"versionType": "git"
},
{
"lessThan": "f5d09de9f1bf9674c6418ff10d0a40cfe29268e1",
"status": "affected",
"version": "530dd9926dc16220d2fae0997f45cda94f5f0864",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/hugetlb.c",
"mm/memory.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.11"
},
{
"lessThan": "6.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.7",
"versionStartIncluding": "6.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "6.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: use aligned address in copy_user_gigantic_page()\n\nIn current kernel, hugetlb_wp() calls copy_user_large_folio() with the\nfault address. Where the fault address may be not aligned with the huge\npage size. Then, copy_user_large_folio() may call\ncopy_user_gigantic_page() with the address, while\ncopy_user_gigantic_page() requires the address to be huge page size\naligned. So, this may cause memory corruption or information leak,\naddtional, use more obvious naming \u0027addr_hint\u0027 instead of \u0027addr\u0027 for\ncopy_user_gigantic_page()."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The bug is reached through a local page fault on a hugetlb mapping created by the calling process (mmap MAP_HUGETLB / hugetlbfs MAP_PRIVATE), with no network or remote component. Exploitation requires the attacker to execute code on the target system.\nAC:L - The attacker fully and deterministically controls the faulting address handed to hugetlb_wp() \u2014 simply writing to any non-huge-page-aligned offset in a private gigantic hugetlb mapping guarantees the misaligned vaddr, with no race, no timing window, and no dependence on memory layout. Gigantic hugetlb pools are a widely deployed, routinely provisioned configuration (databases, DPDK, KVM hosts).\nPR:L - Any unprivileged local user can reach the path \u2014 mmap(MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB|MAP_HUGE_1GB) uses HUGETLB_ANON_FILE, which bypasses the can_do_hugetlb_shm() capability gate that only guards SHM_HUGETLB, and an open hugetlbfs file mapped MAP_PRIVATE works equally well. No CAP_IPC_LOCK, CAP_SYS_ADMIN, or root is needed.\nUI:N - The attacker triggers the COW fault entirely within its own process by writing to its own mapping; no victim action, no file to open, no filesystem to mount.\nS:U - The corruption and disclosure occur in memory managed by the same kernel security authority; no VM escape, IOMMU, or sandbox boundary is crossed by the flaw itself.\nC:H - The commit states the misalignment \"may cause memory corruption or information leak\" \u2014 on cache-aliasing architectures the wrong vaddr selects the wrong cache color in kmap_coherent()/the flush decision, so the newly allocated gigantic folio can expose residual contents of a previously-freed 1GB-scale page (another process\u0027s or a KVM guest\u0027s data) directly to the attacker\u0027s userspace mapping.\nI:H - The copy is performed through an incorrectly colored/flushed mapping across every subpage of the gigantic folio, so attacker-reachable data is silently written to or left in the wrong cache alias, corrupting up to a gigabyte of page contents including memory backing KVM guests.\nA:H - Silent corruption of an entire gigantic folio\u0027s contents \u2014 code, stack, page-table-adjacent guest RAM, or application data \u2014 leads to unpredictable faults and crashes, and can be triggered repeatedly by an unprivileged user for as long as gigantic pages remain in the pool."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:43:15.492Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/cb12d61361ce769672c7c7bd32107252598cdd8b"
},
{
"url": "https://git.kernel.org/stable/c/f5d09de9f1bf9674c6418ff10d0a40cfe29268e1"
}
],
"title": "mm: use aligned address in copy_user_gigantic_page()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-51729",
"datePublished": "2025-01-11T12:35:38.375Z",
"dateReserved": "2025-01-11T12:33:33.687Z",
"dateUpdated": "2026-08-05T11:43:15.492Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…