CVE-2023-53658

What it actually does

Null pointer dereference during driver removal when neither hif_mspi nor mspi resource is present, because probe returns success without setting driver data.

Why it matters to the business

Kernel crashes or system instability can occur during device removal or module unload on affected Linux systems, potentially disrupting services and requiring reboots.

How an attack unfolds

An attacker with local access loads or triggers the bcm-qspi driver probe without the required resources present, allowing the module to register successfully; on subsequent removal the null driver data is dereferenced leading to a crash.

How to fix it

Update the Linux kernel to a version containing commit a91c34357afcfaa5307e254f22a8452550a07b34 or later; rebuild and deploy the fixed bcm-qspi driver.

How to confirm the fix worked

Verify the presence of the fix commit in the kernel source, confirm devm_ioremap_resource is called unconditionally in probe, and test module load/unload on hardware lacking the resources.

Typical attack path

1. Obtain local access or execute code on target system
2. Trigger bcm-qspi probe without hif_mspi or mspi resources
3. Perform driver or device removal to induce null dereference

How to detect it

Review kernel logs for null pointer dereference crashes involving bcm-qspi or spi master unregister paths; inspect dmesg and crash dumps for platform_get_drvdata returning NULL followed by dereference.

• bcm-qspi
• platform_get_drvdata
• spi_master
• devm_ioremap_resource

What your security team should do

• Apply the kernel patch containing a91c34357afcfaa5307e254f22a8452550a07b34 immediately on all affected systems
• Prioritize updates for container and embedded deployments using bcm-qspi
• Monitor for related privilege-escalation attempts listed under similar kernel CVEs