CVE-2024-41077

What it actually does

The null_blk module fails to validate that the block size parameter is between 512 and PAGE_SIZE and a power of two, allowing invalid values such as 1536 that trigger a null pointer dereference and kernel oops on module load.

Why it matters to the business

Systems using the null_blk test module in development, testing, or specialized workloads may experience unexpected kernel crashes, leading to downtime and potential data loss in affected environments; low prevalence outside controlled testing reduces widespread operational risk.

How an attack unfolds

An attacker with local access to load kernel modules supplies an invalid block size such as bs=1536 to null_blk, bypassing the incomplete validation check and causing a null pointer dereference that crashes the kernel; listed threat actor campaigns involving Linux kernel privilege escalation highlight the general class of issues but no public exploitation of this specific flaw is known.

How to fix it

Apply the upstream fix from commit 9625afe1dd4a158a14bb50f81af9e2dac634c0b1 or upgrade to a Linux kernel version containing this commit; rebuild and reload null_blk only after the corrected validation logic is present.

How to confirm the fix worked

Confirm the presence of commit 9625afe1dd4a158a14bb50f81af9e2dac634c0b1 in the kernel source or running kernel; attempt to load null_blk with bs=1536 and verify no oops occurs; inspect module initialization code for the updated block-size range and power-of-two checks.

Typical attack path

1. Obtain local access sufficient to load kernel modules
2. Invoke modprobe or insmod on null_blk with bs parameter set to an invalid value such as 1536
3. Trigger the missing validation path leading to null pointer dereference
4. Kernel oops occurs, resulting in system instability or crash

How to detect it

Review kernel logs and dmesg for null_blk oops or null pointer dereference messages around module load events; search system audit logs for invocations of modprobe or insmod targeting null_blk with non-standard block size parameters.

• null_blk would Oops due to a null pointer deref
• bs=1536
• null_blk: invalid block size

What your security team should do

• Prioritize patching kernels that include null_blk if used in any environment
• Restrict module loading to trusted users via kernel module signing and allowlists
• Monitor for kernel oops reports involving null_blk in logs
• Audit any automated test or CI pipelines that load null_blk with custom parameters