{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2024-51729","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2025-01-11T12:33:33.687Z","datePublished":"2025-01-11T12:35:38.375Z","dateUpdated":"2026-08-05T11:43:15.492Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T11:43:15.492Z"},"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 'addr_hint' instead of 'addr' for\ncopy_user_gigantic_page()."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"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() — 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 — 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\" — 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's or a KVM guest's data) directly to the attacker's 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's contents — code, stack, page-table-adjacent guest RAM, or application data — 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."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["mm/hugetlb.c","mm/memory.c"],"versions":[{"version":"530dd9926dc16220d2fae0997f45cda94f5f0864","lessThan":"cb12d61361ce769672c7c7bd32107252598cdd8b","status":"affected","versionType":"git"},{"version":"530dd9926dc16220d2fae0997f45cda94f5f0864","lessThan":"f5d09de9f1bf9674c6418ff10d0a40cfe29268e1","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["mm/hugetlb.c","mm/memory.c"],"versions":[{"version":"6.11","status":"affected"},{"version":"0","lessThan":"6.11","status":"unaffected","versionType":"semver"},{"version":"6.12.7","lessThanOrEqual":"6.12.*","status":"unaffected","versionType":"semver"},{"version":"6.13","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.11","versionEndExcluding":"6.12.7"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.11","versionEndExcluding":"6.13"}]}]}],"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"}}}}