CVE-2024-41032
Medium
Elevated severity or exploit probability.
CVSS base
7.8
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS — probability of exploitation (30 days)
0.3%
22.8th percentile
CISA KEV
Not listed
Weakness / dates
—
Published 2024-07-29 · modified 2026-08-04
CVSS breakdown
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
| Attack Vector | L | Local |
| Attack Complexity | L | Low |
| Privileges Required | L | Low |
| User Interaction | N | None |
| Scope | U | Unchanged |
| Confidentiality | H | High |
| Integrity | H | High |
| Availability | H | High |
Timeline
- 2024-07-29 — Published (NVD)
- 2026-08-04 — Last modified (NVD)
Description
In the Linux kernel, the following vulnerability has been resolved: mm: vmalloc: check if a hash-index is in cpu_possible_mask The problem is that there are systems where cpu_possible_mask has gaps between set CPUs, for example SPARC. In this scenario addr_to_vb_xa() hash function can return an index which accesses to not-possible and not setup CPU area using per_cpu() macro. This results in an oops on SPARC. A per-cpu vmap_block_queue is also used as hash table, incorrectly assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index to a next possible CPU.
Affected
References
- https://git.kernel.org/stable/c/28acd531c9a365dac01b32e6bc54aed8c1429bcb
- https://git.kernel.org/stable/c/47f9b6e49b422392fb0e348a65eb925103ba1882
- https://git.kernel.org/stable/c/a34acf30b19bc4ee3ba2f1082756ea2604c19138
- https://git.kernel.org/stable/c/28acd531c9a365dac01b32e6bc54aed8c1429bcb
- https://git.kernel.org/stable/c/47f9b6e49b422392fb0e348a65eb925103ba1882
- https://git.kernel.org/stable/c/a34acf30b19bc4ee3ba2f1082756ea2604c19138