CVE-2024-35872

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2024-35872", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-05-17T13:50:33.108Z", "datePublished": "2024-05-19T08:34:30.096Z", "dateUpdated": "2026-08-05T11:30:33.747Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T11:30:33.747Z"}, "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."}], "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 \u2014 `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 \u2014 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 \u2014 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 \u2014 pages deliberately removed from the kernel direct map become pinnable and reachable by kernel subsystems and DMA engines (splice\u2192socket, 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 \u2014 `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) \u2014 and an unprivileged user can trigger it on demand and repeatedly."}]}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["include/linux/secretmem.h"], "versions": [{"version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "6564b014af92b677c1f07c44d7f5b595d589cf6e", "status": "affected", "versionType": "git"}, {"version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "9c2b4b657739ecda38e3b383354a29566955ac48", "status": "affected", "versionType": "git"}, {"version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "43fad1d0284de30159661d0badfc3cbaf7e6f8f8", "status": "affected", "versionType": "git"}, {"version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "201e4aaf405dfd1308da54448654053004c579b5", "status": "affected", "versionType": "git"}, {"version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "65291dcfcf8936e1b23cfd7718fdfde7cfaf7706", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["include/linux/secretmem.h"], "versions": [{"version": "5.14", "status": "affected"}, {"version": "0", "lessThan": "5.14", "status": "unaffected", "versionType": "semver"}, {"version": "5.15.154", "lessThanOrEqual": "5.15.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.85", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.26", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.8.5", "lessThanOrEqual": "6.8.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.9", "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": "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"}]}]}], "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"}], "title": "mm/secretmem: fix GUP-fast succeeding on secretmem folios", "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": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-06-04T17:34:09.055Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T03:21:48.571Z"}, "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"]}]}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"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": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T03:21:48.571Z"}}, {"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": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-05-23T19:01:24.962Z"}, "title": "CISA ADP Vulnrichment"}], "cna": {"title": "mm/secretmem: fix GUP-fast succeeding on secretmem folios", "metrics": [{"cvssV3_1": {"version": "3.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"}, "scenarios": [{"lang": "en", "value": "AV:L - The whole path is local syscalls \u2014 `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 \u2014 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 \u2014 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 \u2014 pages deliberately removed from the kernel direct map become pinnable and reachable by kernel subsystems and DMA engines (splice\u2192socket, 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 \u2014 `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) \u2014 and an unprivileged user can trigger it on demand and repeatedly."}]}], "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "6564b014af92b677c1f07c44d7f5b595d589cf6e", "versionType": "git"}, {"status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "9c2b4b657739ecda38e3b383354a29566955ac48", "versionType": "git"}, {"status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "43fad1d0284de30159661d0badfc3cbaf7e6f8f8", "versionType": "git"}, {"status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "201e4aaf405dfd1308da54448654053004c579b5", "versionType": "git"}, {"status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "lessThan": "65291dcfcf8936e1b23cfd7718fdfde7cfaf7706", "versionType": "git"}], "programFiles": ["include/linux/secretmem.h"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.14"}, {"status": "unaffected", "version": "0", "lessThan": "5.14", "versionType": "semver"}, {"status": "unaffected", "version": "5.15.154", "versionType": "semver", "lessThanOrEqual": "5.15.*"}, {"status": "unaffected", "version": "6.1.85", "versionType": "semver", "lessThanOrEqual": "6.1.*"}, {"status": "unaffected", "version": "6.6.26", "versionType": "semver", "lessThanOrEqual": "6.6.*"}, {"status": "unaffected", "version": "6.8.5", "versionType": "semver", "lessThanOrEqual": "6.8.*"}, {"status": "unaffected", "version": "6.9", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["include/linux/secretmem.h"], "defaultStatus": "affected"}], "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"}], "x_generator": {"engine": "bippy-1.2.0"}, "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."}], "cpeApplicability": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "versionEndExcluding": "5.15.154", "versionStartIncluding": "5.14"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "versionEndExcluding": "6.1.85", "versionStartIncluding": "5.14"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "versionEndExcluding": "6.6.26", "versionStartIncluding": "5.14"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "versionEndExcluding": "6.8.5", "versionStartIncluding": "5.14"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "versionEndExcluding": "6.9", "versionStartIncluding": "5.14"}], "operator": "OR"}]}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T11:30:33.747Z"}}}, "cveMetadata": {"cveId": "CVE-2024-35872", "state": "PUBLISHED", "dateUpdated": "2026-08-05T11:30:33.747Z", "dateReserved": "2024-05-17T13:50:33.108Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-05-19T08:34:30.096Z", "assignerShortName": "Linux"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "product": "Linux", "programFiles": ["include/linux/secretmem.h"], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [{"lessThan": "6564b014af92b677c1f07c44d7f5b595d589cf6e", "status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "versionType": "git"}, {"lessThan": "9c2b4b657739ecda38e3b383354a29566955ac48", "status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "versionType": "git"}, {"lessThan": "43fad1d0284de30159661d0badfc3cbaf7e6f8f8", "status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "versionType": "git"}, {"lessThan": "201e4aaf405dfd1308da54448654053004c579b5", "status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "versionType": "git"}, {"lessThan": "65291dcfcf8936e1b23cfd7718fdfde7cfaf7706", "status": "affected", "version": "1507f51255c9ff07d75909a84e7c0d7f3c4b2f49", "versionType": "git"}]}, {"defaultStatus": "affected", "product": "Linux", "programFiles": ["include/linux/secretmem.h"], "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "versions": [{"status": "affected", "version": "5.14"}, {"lessThan": "5.14", "status": "unaffected", "version": "0", "versionType": "semver"}, {"lessThanOrEqual": "5.15.*", "status": "unaffected", "version": "5.15.154", "versionType": "semver"}, {"lessThanOrEqual": "6.1.*", "status": "unaffected", "version": "6.1.85", "versionType": "semver"}, {"lessThanOrEqual": "6.6.*", "status": "unaffected", "version": "6.6.26", "versionType": "semver"}, {"lessThanOrEqual": "6.8.*", "status": "unaffected", "version": "6.8.5", "versionType": "semver"}, {"lessThanOrEqual": "*", "status": "unaffected", "version": "6.9", "versionType": "original_commit_for_fix"}]}], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "0290B9D4-539A-4C65-88D4-3A68FBF7F40B", "versionEndExcluding": "5.15.154", "versionStartIncluding": "5.14", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "325665BF-2409-49D9-B391-39AD4566FDBD", "versionEndExcluding": "6.1.85", "versionStartIncluding": "5.16", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "C520696A-A594-4FFC-A32D-12DA535CE911", "versionEndExcluding": "6.6.26", "versionStartIncluding": "6.2", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "DBD6C99E-4250-4DFE-8447-FF2075939D10", "versionEndExcluding": "6.8.5", "versionStartIncluding": "6.7", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:*", "matchCriteriaId": "22BEDD49-2C6D-402D-9DBF-6646F6ECD10B", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.9:rc2:*:*:*:*:*:*", "matchCriteriaId": "DF73CB2A-DFFD-46FB-9BFE-AA394F27EA37", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "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."}, {"lang": "es", "value": " En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mm/secretmem: corrige el \u00e9xito r\u00e1pido de GUP en folios secretmem folio_is_secretmem() actualmente depende de que los folios secretmem sean folios LRU, para guardar algunos ciclos. Sin embargo, las publicaciones pueden residir en un lote de publicaciones sin el indicador LRU establecido o tener su indicador LRU borrado temporalmente. En consecuencia, la bandera LRU no es fiable para este fin. En particular, este es el caso cuando secretmem_fault() asigna una p\u00e1gina nueva y llama a filemap_add_folio()->folio_add_lru(). La publicaci\u00f3n podr\u00eda agregarse al lote de publicaciones por CPU y no se establecer\u00e1 el indicador LRU hasta que el lote se drene usando, por ejemplo, lru_add_drain(). En consecuencia, es posible que folio_is_secretmem() no detecte folios secretmem y GUP-fast puede lograr capturar un folio secretmem, bloqueando el kernel cuando m\u00e1s tarde intentemos leer/escribir en el folio, porque el folio no se ha desasignado del mapa directo. Solucionarlo eliminando ese cheque poco confiable."}], "id": "CVE-2024-35872", "lastModified": "2026-08-04T11:18:03.793", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 5.9, "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "type": "Secondary"}, {"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2024-35872", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2024-05-20T15:13:36.224766Z", "version": "2.0.3"}}]}, "published": "2024-05-19T09:15:08.600", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/201e4aaf405dfd1308da54448654053004c579b5"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/43fad1d0284de30159661d0badfc3cbaf7e6f8f8"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/65291dcfcf8936e1b23cfd7718fdfde7cfaf7706"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/6564b014af92b677c1f07c44d7f5b595d589cf6e"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/9c2b4b657739ecda38e3b383354a29566955ac48"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Modified", "weaknesses": [{"description": [{"lang": "en", "value": "NVD-CWE-noinfo"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"affected_release": [{"advisory": "RHSA-2024:9315", "cpe": "cpe:/a:redhat:enterprise_linux:9", "package": "kernel-0:5.14.0-503.11.1.el9_5", "product_name": "Red Hat Enterprise Linux 9", "release_date": "2024-11-12T00:00:00Z"}, {"advisory": "RHSA-2024:9315", "cpe": "cpe:/o:redhat:enterprise_linux:9", "package": "kernel-0:5.14.0-503.11.1.el9_5", "product_name": "Red Hat Enterprise Linux 9", "release_date": "2024-11-12T00:00:00Z"}], "bugzilla": {"description": "kernel: mm/secretmem: fix GUP-fast succeeding on secretmem folios", "id": "2281736", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2281736"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "verified"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\nmm/secretmem: fix GUP-fast succeeding on secretmem folios\nfolio_is_secretmem() currently relies on secretmem folios being LRU\nfolios, to save some cycles.\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.\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().\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.\nFix it by removing that unreliable check."], "name": "CVE-2024-35872", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-05-19T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-35872\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-35872\nhttps://lore.kernel.org/linux-cve-announce/2024051941-CVE-2024-35872-4632@gregkh/T"], "threat_severity": "Moderate"}

{}