{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-41032", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-41032" ], "published": "2024-07-29T14:32:49Z", "summary": "mm: vmalloc: check if a hash-index is in cpu_possible_mask", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmalloc: check if a hash-index is in cpu_possible_mask\n\nThe problem is that there are systems where cpu_possible_mask has gaps\nbetween set CPUs, for example SPARC. In this scenario addr_to_vb_xa()\nhash function can return an index which accesses to not-possible and not\nsetup CPU area using per_cpu() macro. This results in an oops on SPARC.\n\nA per-cpu vmap_block_queue is also used as hash table, incorrectly\nassuming the cpu_possible_mask has no gaps. Fix it by adjusting an index\nto a next possible CPU.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.6.20-1+rpt1", "1:6.6.28-1+rpt1", "1:6.6.31-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" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-2712", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v6", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7l", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v8", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-2712", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v6", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7l", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v8", "binary_version": "1:6.6.31-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.41" }, "1:6.6.28-1+rpt1": { "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e", "upstream_version": "6.6.28", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.41" }, "1:6.6.31-1+rpt1": { "linux_commit": "c1432b4bae5b6582f4d32ba381459f33c34d1424", "upstream_version": "6.6.31", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.41" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-41032" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/28acd531c9a365dac01b32e6bc54aed8c1429bcb" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/47f9b6e49b422392fb0e348a65eb925103ba1882" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a34acf30b19bc4ee3ba2f1082756ea2604c19138" } ], "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.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable path is the vmalloc/vmap-block allocator, reached through ordinary local allocation activity (XFS buffer mapping, f2fs/EROFS decompression, videobuf2, udmabuf) rather than through parsing of remote network data. Exploitation requires the attacker to be executing code on the affected system.\nAC:L - On an affected system the faulty index is a pure function of the vmap address, so a local user triggers it deterministically with routine file I/O \u2014 no race to win and no memory layout the attacker cannot influence, since the aliased page is a freed-initmem page returned to the buddy allocator and therefore sprayable.\nPR:L - No capability, namespace, or filesystem-admin check exists anywhere on the path; `vb_alloc()`/`vb_free()` are reached by any unprivileged user reading or writing files on XFS, f2fs (compression), or EROFS, or opening a V4L2/udmabuf device.\nUI:N - The attacker performs the triggering I/O themselves; no victim action, mount, or file-open by another user is needed.\nS:U - The faulty per-CPU access and the resulting corruption are both within the kernel's own security authority, with no crossing of a hypervisor, IOMMU, or sandbox boundary.\nC:H - The bogus per-CPU address aliases a freed initmem page that has been returned to the page allocator, so `xa_load()`/`vmap_ram_vread_iter()` dereference an `xa_head` pointer sourced from attacker-influenceable memory, giving an out-of-bounds/arbitrary kernel read primitive rather than a bounded leak.\nI:H - `xa_insert()` writes into that reallocated page, and `vb_free()` performs `spin_lock()`, `bitmap_clear()`, `WRITE_ONCE()` and `kfree_rcu()` on an unvalidated `vb` pointer loaded from it, yielding arbitrary-write and arbitrary-free primitives suitable for control-flow hijack.\nA:H - The reported and guaranteed outcome is a kernel oops on SPARC (dereferencing the 0xcc-poisoned or reallocated stale percpu alias), plus reachable `BUG_ON(tmp != vb)` in `free_vmap_block()`, causing a panic and full denial of service." } } }