CVE-2021-46995

What it actually does

Missing return after dev_err_probe() in mcp251xfd_probe() causes clk_get_rate() to be called on an ERR_PTR from failed devm_clk_get(), resulting in invalid pointer dereference and kernel oops.

Why it matters to the business

Systems using the MCP251xFD CAN controller may experience kernel crashes during driver initialization, leading to boot failures or hardware unavailability on affected Linux kernels.

How an attack unfolds

The flaw is triggered automatically during device probe when devm_clk_get() returns an error pointer; no attacker-controlled input is required, and the resulting dereference produces a denial-of-service via kernel panic.

How to fix it

Apply the upstream fix that restores the missing return statement after the dev_err_probe() call in drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c; rebuild and deploy the corrected kernel.

How to confirm the fix worked

Inspect the mcp251xfd_probe() function in the kernel source to confirm a return statement immediately follows the dev_err_probe() for the devm_clk_get() failure path; boot-test on affected hardware to verify no oops occurs on clock failure.

Typical attack path

1. Load or bind the mcp251xfd driver to hardware
2. Force devm_clk_get() to fail
3. Execute clk_get_rate() on the error pointer
4. Kernel dereferences invalid address and oopses

How to detect it

Search kernel logs and dmesg for oops traces containing mcp251xfd_probe, devm_clk_get, or clk_get_rate; correlate with device probe failures on CAN controllers.

What your security team should do

• Prioritize kernel update on systems exposing the mcp251xfd driver
• Add kernel oops monitoring for mcp251xfd symbols
• Restrict physical or privileged access that could influence clock device registration