CVE-2024-52319 (GCVE-0-2024-52319)
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 clear_gigantic_page()
In current kernel, hugetlb_no_page() calls folio_zero_user() with the
fault address. Where the fault address may be not aligned with the huge
page size. Then, folio_zero_user() may call clear_gigantic_page() with
the address, while clear_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
clear_gigantic_page().
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/hugetlbfs/inode.c",
"mm/memory.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b79b6fe0737f233f0be1465052b7f0e75f324735",
"status": "affected",
"version": "78fefd04c123493bbf28434768fa577b2153c79b",
"versionType": "git"
},
{
"lessThan": "8aca2bc96c833ba695ede7a45ad7784c836a262e",
"status": "affected",
"version": "78fefd04c123493bbf28434768fa577b2153c79b",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/hugetlbfs/inode.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 clear_gigantic_page()\n\nIn current kernel, hugetlb_no_page() calls folio_zero_user() with the\nfault address. Where the fault address may be not aligned with the huge\npage size. Then, folio_zero_user() may call clear_gigantic_page() with\nthe address, while clear_gigantic_page() requires the address to be huge\npage size aligned. So, this may cause memory corruption or information\nleak, addtional, use more obvious naming \u0027addr_hint\u0027 instead of \u0027addr\u0027 for\nclear_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 page fault on a hugetlbfs/MAP_HUGETLB mapping in the faulting task\u0027s own address space (hugetlb_no_page() \u2192 folio_zero_user()), requiring local execution on the host. There is no network- or adjacent-reachable path into mm/memory.c\u0027s page-zeroing helpers.\nAC:L - The attacker fully and deterministically controls the misalignment \u2014 vmf-\u003ereal_address is the raw faulting address, so simply touching any non-huge-page-aligned byte of the mapping on first fault reproduces the wrong cache-alias selection every time, with no race and no memory-layout guessing.\nPR:L - An ordinary unprivileged user can allocate the mapping: mmap(MAP_HUGETLB|MAP_HUGE_*) uses HUGETLB_ANONHUGE_INODE, which bypasses the can_do_hugetlb_shm() capability gate in hugetlb_file_setup(), and hugetlbfs mounts are commonly world-accessible. No capability, and no CAP_IPC_LOCK or hugetlb_shm_group membership, is needed.\nUI:N - The attacker triggers the flaw entirely on their own by faulting a mapping they created themselves; no action by any other user or administrator is required at attack time.\nS:U - The mis-zeroed page and the leaked/corrupted data both live within the same kernel-managed security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - Because the gigantic folio is cleared through the wrong virtual cache alias (sparc64 clear_user_page\u0027s TLBTEMP color bit, sh\u0027s skipped __flush_purge_region), the user reads stale lines and recovers the prior contents of that physical memory \u2014 potentially hundreds of megabytes to gigabytes of another process\u0027s or KVM guest\u0027s freed hugetlb data. The fix commit explicitly cites \"information leak\".\nI:H - The fix commit explicitly states the unaligned address \"may cause memory corruption\": dirty stale aliased cache lines can be written back over the region the kernel just zeroed, silently corrupting memory in a page the kernel guarantees is zero-filled, including shared hugetlbfs pages consumed by other processes.\nA:H - Silent corruption of hugetlbfs-backed memory that callers assume is zeroed \u2014 typically KVM guest RAM or a database\u0027s shared segment on these gigantic-page deployments \u2014 reliably produces crashes and hangs in the affected workloads, and the higher value is taken given the fix commit\u0027s own \"memory corruption\" characterization."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:43:16.556Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b79b6fe0737f233f0be1465052b7f0e75f324735"
},
{
"url": "https://git.kernel.org/stable/c/8aca2bc96c833ba695ede7a45ad7784c836a262e"
}
],
"title": "mm: use aligned address in clear_gigantic_page()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-52319",
"datePublished": "2025-01-11T12:35:39.280Z",
"dateReserved": "2025-01-11T12:33:33.694Z",
"dateUpdated": "2026-08-05T11:43:16.556Z",
"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…