CVE-2024-34777

What it actually does

Lack of bounds checking on node ID argument passed to map_benchmark_ioctl allows node_possible() and subsequent node_state() calls to receive values outside the valid [0, MAX_NUMNODES-1] range, resulting in wild memory reads via KASAN-detected out-of-bounds access in the nodemask bit operations.

Why it matters to the business

Systems exposing the dma mapping benchmark interface can experience kernel crashes or memory corruption during benchmark operations, reducing stability for workloads that rely on NUMA-aware DMA testing or custom node binding in Linux environments.

How an attack unfolds

An attacker with local access invokes the map_benchmark_ioctl through the debugfs dma_map_benchmark interface, supplying a node ID outside the valid range or using NUMA_NO_NODE inappropriately; the missing bounds check leads directly to invalid bit test operations and potential kernel panic or information leak.

How to fix it

Upgrade the Linux kernel to a version containing commit 35d31c8bd4722b107f5a2f5ddddce839de04b936 or later; rebuild and reboot affected systems; disable the benchmark module if it is not required for operations.

How to confirm the fix worked

Confirm the presence of commit 35d31c8bd4722b107f5a2f5ddddce839de04b936 in the running kernel source or package; attempt to reproduce the original KASAN report with an out-of-range node ID and verify the crash no longer occurs; inspect kernel logs for absence of the wild-memory-access signature.

Typical attack path

1. Obtain local access to a system running an affected kernel version
2. Locate or mount the debugfs dma_map_benchmark interface
3. Issue an ioctl call with a crafted node ID argument outside [0, MAX_NUMNODES-1]
4. Trigger node_state() and _test_bit operations on the invalid value
5. Cause KASAN wild-memory-access or kernel instability

How to detect it

Search kernel logs and dmesg for KASAN reports referencing map_benchmark_ioctl, variable_test_bit, or node_state with wild-memory-access addresses; review audit logs for unusual ioctl activity on debugfs dma mapping files; examine process execution of dma_map_benchma or similar benchmark binaries.

What your security team should do

• Prioritize kernel updates on any systems exposing DMA benchmark interfaces or running custom NUMA workloads
• Review and restrict access to debugfs and the dma_map_benchmark device for unprivileged users
• Monitor kernel update channels for backports of the node ID validation fix
• Test the patched kernel in staging environments before broad deployment