{ "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" } } } }