CVE-2024-40963

What it actually does

The flaw permits CBR address to remain 0 on BCM6358 devices when booted from TP1 because BMIPS_GET_CBR() returns 0 and existing checks for RAC flush disablement do not validate the address; subsequent calls to arch_sync_dma_for_cpu_all then dereference the invalid address and trigger a kernel panic.

Why it matters to the business

Affected MIPS BCM6358 systems running the vulnerable kernel may experience repeated crashes during normal DMA operations, resulting in unplanned downtime and service interruption; ecosystem prevalence is high across Linux distributions but exploitation risk remains low given the specific hardware and boot conditions required.

How an attack unfolds

An attacker or misconfigured boot environment forces the system to boot from TP1 on BCM6358 hardware; BMIPS_GET_CBR() returns 0, the insufficient RAC flush check passes, and any subsequent arch_sync_dma_for_cpu_all invocation dereferences the null CBR causing an immediate kernel panic. No named threat actors have been observed exploiting this specific issue.

How to fix it

Update the Linux kernel to commit 457391b0380335d5e9a5babdec90ac53928b23b4 or later; rebuild and deploy the fixed kernel on all BCM6358 devices; verify the CBR address check is present before enabling RAC flush.

How to confirm the fix worked

Confirm the running kernel contains commit 457391b0380335d5e9a5babdec90ac53928b23b4; inspect arch/mips/bmips/setup.c for the added CBR validity check; test boot from TP1 and verify no panic occurs on DMA operations.

Typical attack path

1. Boot the BCM6358 system from TP1
2. Allow the kernel to initialize with BMIPS_GET_CBR() returning 0
3. Trigger any code path that calls arch_sync_dma_for_cpu_all
4. Observe kernel panic due to invalid CBR dereference

How to detect it

Review kernel logs and dmesg for panic messages referencing arch_sync_dma_for_cpu_all, BMIPS_GET_CBR returning 0, or CBR address validation failures on mips bmips platforms; correlate with boot logs indicating TP1 startup.

What your security team should do

• Apply the fixed kernel commit 457391b0380335d5e9a5babdec90ac53928b23b4 immediately on all BCM6358 hardware
• Restrict or monitor TP1 boot configurations in production environments until patched
• Include kernel panic logs mentioning BMIPS_GET_CBR or CBR==0 in SOC monitoring rules
• Track EPSS trend (stable at 0.0029) and re-evaluate if new exploitation reports appear