{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-35797", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-35797" ], "published": "2024-05-17T13:23:58Z", "summary": "mm: cachestat: fix two shmem bugs", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: cachestat: fix two shmem bugs\n\nWhen cachestat on shmem races with swapping and invalidation, there\nare two possible bugs:\n\n1) A swapin error can have resulted in a poisoned swap entry in the\n shmem inode's xarray. Calling get_shadow_from_swap_cache() on it\n will result in an out-of-bounds access to swapper_spaces[].\n\n Validate the entry with non_swap_entry() before going further.\n\n2) When we find a valid swap entry in the shmem's inode, the shadow\n entry in the swapcache might not exist yet: swap IO is still in\n progress and we're before __remove_mapping; swapin, invalidation,\n or swapoff have removed the shadow from swapcache after we saw the\n shmem swap entry.\n\n This will send a NULL to workingset_test_recent(). The latter\n purely operates on pointer bits, so it won't crash - node 0, memcg\n ID 0, eviction timestamp 0, etc. are all valid inputs - but it's a\n bogus test. In theory that could result in a false \"recently\n evicted\" count.\n\n Such a false positive wouldn't be the end of the world. But for\n code clarity and (future) robustness, be explicit about this case.\n\n Bail on get_shadow_from_swap_cache() returning NULL.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.6.20-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v6", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.24" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-35797" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b79f9e1ff27c994a4c452235ba09e672ec698e23" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d962f6c583458037dc7e529659b2b02b9dd3d94b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/24a0e73d544439bb9329fbbafac44299e548a677" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d5d39c707a4cf0bcc84680178677b97aa2cb2627" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.1, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerability is reached only through the `cachestat(2)` syscall on a local file descriptor for a shmem/tmpfs mapping (memfd, /dev/shm, or any readable tmpfs file). There is no network or remote-peer path into `filemap_cachestat()`.\nAC:L - Once a poisoned swap entry exists in a shmem inode it persists until truncate, and every `cachestat()` call covering that index deterministically and repeatably performs the out-of-bounds `swapper_spaces[]` access; the attacker additionally controls both sides of the cachestat-vs-swapping/invalidation race and can drive unbounded shmem swap I/O (large tmpfs files plus memory pressure) to provoke the swapin error, which is routine on flash-backed embedded/IoT swap and network-backed swap in diskless/cloud deployments.\nPR:L - `cachestat(2)` performs only `fdget()` with no capability or permission check whatsoever in the affected versions, and any unprivileged user can create a shmem mapping via `memfd_create()` or `/dev/shm`. No elevated privileges or namespace tricks are needed.\nUI:N - The attacker triggers the flaw entirely from their own process with a single syscall on a file descriptor they already hold. No action by any other user or victim process is required.\nS:U - The out-of-bounds access, wild dereference and resulting oops are all confined to the kernel's own security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - The read past the end of `swapper_spaces[]` yields an unvalidated non-pointer value that is dereferenced as a `struct address_space` and walked as an xarray, so the kernel reads memory at an address it never bounds-checked; the value derived from that walk feeds `workingset_test_recent()` whose outcome is reflected in the `nr_recently_evicted` field copied back to userspace, forming a kernel-memory disclosure oracle. This is an unbounded out-of-bounds read, not a read strictly limited to a few bytes.\nI:N - The faulty path only performs reads (`xa_load`), and the memcg reference taken in `workingset_test_recent()` is released on all paths, so no kernel memory is written or corrupted and no write or control-flow-hijack primitive is produced. The only integrity effect is an inaccurate statistics counter returned to the caller.\nA:H - The out-of-bounds `swapper_spaces[31]` value is almost always zero (or unmapped garbage), producing a NULL/wild pointer dereference and kernel oops inside an `rcu_read_lock()` critical section; the leaked RCU nesting on task death can escalate to RCU stalls and a system-wide hang, and `panic_on_oops` systems panic outright." } } }