{"id":"CVE-2024-35872","state":"PUBLISHED","title":"mm/secretmem: fix GUP-fast succeeding on secretmem folios","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/secretmem: fix GUP-fast succeeding on secretmem folios\n\nfolio_is_secretmem() currently relies on secretmem folios being LRU\nfolios, to save some cycles.\n\nHowever, folios might reside in a folio batch without the LRU flag set, or\ntemporarily have their LRU flag cleared.  Consequently, the LRU flag is\nunreliable for this purpose.\n\nIn particular, this is the case when secretmem_fault() allocates a fresh\npage and calls filemap_add_folio()->folio_add_lru().  The folio might be\nadded to the per-cpu folio batch and won't get the LRU flag set until the\nbatch was drained using e.g., lru_add_drain().\n\nConsequently, folio_is_secretmem() might not detect secretmem folios and\nGUP-fast can succeed in grabbing a secretmem folio, crashing the kernel\nwhen we would later try reading/writing to the folio, because the folio\nhas been unmapped from the directmap.\n\nFix it by removing that unreliable check.","publishedAt":"2024-05-19T08:34:30.096Z","updatedAt":"2026-08-05T11:30:33.747Z","severity":{"score":7.8,"label":"High","version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","source":"Linux"},"assigner":"Linux","products":["Linux Linux"],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"6564b014af92b677c1f07c44d7f5b595d589cf6e","versionType":"git"},{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"9c2b4b657739ecda38e3b383354a29566955ac48","versionType":"git"},{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"43fad1d0284de30159661d0badfc3cbaf7e6f8f8","versionType":"git"},{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"201e4aaf405dfd1308da54448654053004c579b5","versionType":"git"},{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"65291dcfcf8936e1b23cfd7718fdfde7cfaf7706","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["include/linux/secretmem.h"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"5.14","status":"affected"},{"version":"0","status":"unaffected","lessThan":"5.14","versionType":"semver"},{"version":"5.15.154","status":"unaffected","lessThanOrEqual":"5.15.*","versionType":"semver"},{"version":"6.1.85","status":"unaffected","lessThanOrEqual":"6.1.*","versionType":"semver"},{"version":"6.6.26","status":"unaffected","lessThanOrEqual":"6.6.*","versionType":"semver"},{"version":"6.8.5","status":"unaffected","lessThanOrEqual":"6.8.*","versionType":"semver"},{"version":"6.9","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["include/linux/secretmem.h"]}],"references":["https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e","https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48","https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8","https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5","https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706"],"weaknesses":[],"ingestedAt":"2026-10-29T20:07:30.303Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2024/35xxx/CVE-2024-35872.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2024-35872","state":"PUBLISHED","datePublished":"2024-05-19T08:34:30.096Z","dateUpdated":"2026-08-05T11:30:33.747Z","assignerShortName":"Linux","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateReserved":"2024-05-17T13:50:33.108Z"},"containers":{"cna":{"title":"mm/secretmem: fix GUP-fast succeeding on secretmem folios","descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/secretmem: fix GUP-fast succeeding on secretmem folios\n\nfolio_is_secretmem() currently relies on secretmem folios being LRU\nfolios, to save some cycles.\n\nHowever, folios might reside in a folio batch without the LRU flag set, or\ntemporarily have their LRU flag cleared.  Consequently, the LRU flag is\nunreliable for this purpose.\n\nIn particular, this is the case when secretmem_fault() allocates a fresh\npage and calls filemap_add_folio()->folio_add_lru().  The folio might be\nadded to the per-cpu folio batch and won't get the LRU flag set until the\nbatch was drained using e.g., lru_add_drain().\n\nConsequently, folio_is_secretmem() might not detect secretmem folios and\nGUP-fast can succeed in grabbing a secretmem folio, crashing the kernel\nwhen we would later try reading/writing to the folio, because the folio\nhas been unmapped from the directmap.\n\nFix it by removing that unreliable check."}],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"6564b014af92b677c1f07c44d7f5b595d589cf6e","versionType":"git"},{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"9c2b4b657739ecda38e3b383354a29566955ac48","versionType":"git"},{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"43fad1d0284de30159661d0badfc3cbaf7e6f8f8","versionType":"git"},{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"201e4aaf405dfd1308da54448654053004c579b5","versionType":"git"},{"version":"1507f51255c9ff07d75909a84e7c0d7f3c4b2f49","status":"affected","lessThan":"65291dcfcf8936e1b23cfd7718fdfde7cfaf7706","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["include/linux/secretmem.h"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"5.14","status":"affected"},{"version":"0","status":"unaffected","lessThan":"5.14","versionType":"semver"},{"version":"5.15.154","status":"unaffected","lessThanOrEqual":"5.15.*","versionType":"semver"},{"version":"6.1.85","status":"unaffected","lessThanOrEqual":"6.1.*","versionType":"semver"},{"version":"6.6.26","status":"unaffected","lessThanOrEqual":"6.6.*","versionType":"semver"},{"version":"6.8.5","status":"unaffected","lessThanOrEqual":"6.8.*","versionType":"semver"},{"version":"6.9","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["include/linux/secretmem.h"]}],"references":[{"url":"https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e"},{"url":"https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48"},{"url":"https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8"},{"url":"https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5"},{"url":"https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706"}],"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 whole path is local syscalls — `memfd_secret(2)`, `mmap(2)` to fault the folio into the per-CPU batch, then any GUP-fast consumer such as `vmsplice(2)`, O_DIRECT, or io_uring buffer registration. No remote peer data reaches `folio_is_secretmem()`.\nAC:L - The window is not a race the attacker must win but a state the attacker creates: faulting a fresh secretmem page deterministically leaves it in the per-CPU folio batch without `PG_lru`, and the immediately following GUP-fast call on the same CPU always sees the stale flag — the upstream selftest reproduces it every run, with unlimited retries available.\nPR:L - Only an unprivileged local account is needed: `memfd_secret(2)` performs no capability check, `CONFIG_SECRETMEM` is `default y` on x86/arm64/riscv, and `secretmem.enable` defaults to 1 since v6.5, with `secretmem_mmap()` needing only default RLIMIT_MEMLOCK headroom for a single page.\nUI:N - The attacking process performs every step itself — create the fd, fault the page, invoke the GUP-fast consumer. No victim action, mount, or file open is involved.\nS:U - The bypassed check and the resulting oops/exposure are both inside the kernel's own memory-management authority; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - It defeats secretmem's core confidentiality guarantee — pages deliberately removed from the kernel direct map become pinnable and reachable by kernel subsystems and DMA engines (splice→socket, O_DIRECT, and even read-only longterm pins passed in the vulnerable tree), so key material secretmem exists to keep out of kernel reach can be read out to a file or the wire, and the resulting oops additionally dumps kernel addresses and stack state.\nI:H - The same bypass works with `FOLL_WRITE`, letting kernel copies and device DMA write into memory the design guarantees is unwritable from kernel context and corrupt the protected secret; the unhandled kernel fault also aborts operations mid-way, leaving pinned folios and held mm/pipe/filesystem locks behind.\nA:H - Any subsequent CPU access to the pinned folio through the cleared direct-map entry is an unhandled kernel page fault — `page_fault_oops()` in process context, and a fatal `Fatal exception in interrupt` panic when it lands in softirq (e.g. skb copy after splice to a socket) — and an unprivileged user can trigger it on demand and repeatedly."}]}],"providerMetadata":{"shortName":"Linux","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateUpdated":"2026-08-05T11:30:33.747Z"},"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.14","versionEndExcluding":"5.15.154"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.14","versionEndExcluding":"6.1.85"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.14","versionEndExcluding":"6.6.26"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.14","versionEndExcluding":"6.8.5"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.14","versionEndExcluding":"6.9"}]}]}],"x_generator":{"engine":"bippy-1.2.0"}},"adp":[{"title":"CISA ADP Vulnrichment","metrics":[{"other":{"type":"ssvc","content":{"id":"CVE-2024-35872","role":"CISA Coordinator","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"version":"2.0.3","timestamp":"2024-05-20T15:13:36.224766Z"}}}],"providerMetadata":{"shortName":"CISA-ADP","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","dateUpdated":"2024-06-04T17:34:09.055Z"}},{"title":"CVE Program Container","references":[{"url":"https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e","tags":["x_transferred"]},{"url":"https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48","tags":["x_transferred"]},{"url":"https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8","tags":["x_transferred"]},{"url":"https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5","tags":["x_transferred"]},{"url":"https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706","tags":["x_transferred"]}],"providerMetadata":{"shortName":"CVE","orgId":"af854a3a-2127-422b-91ae-364da2661108","dateUpdated":"2024-08-02T03:21:48.571Z"}}]}}}