CVE-2025-68368

What it actually does

A NULL pointer dereference occurs during IO operations in md_update_sb because bioset was never initialized in mddev_init, allowing metadata updates via sysfs before md_run completes.

Why it matters to the business

Routine storage configuration changes on Linux systems using md devices can trigger kernel crashes, causing downtime, data access loss, and unplanned reboots across servers and appliances.

How an attack unfolds

An attacker with local privileges uses mdadm to create an array, sets it inactive via sysfs, then writes a new level value to trigger an early metadata update that dereferences the uninitialized bioset.

How to fix it

Update the Linux kernel to a version containing commit 9d37fe37dfa0833a8768740f0575e0ffd793cb4a or later that initializes bioset inside mddev_init; apply equivalent fixes from stable trees.

How to confirm the fix worked

Confirm bioset initialization occurs unconditionally in mddev_init by inspecting kernel source or checking the fixed commit hash is present in the running kernel build.

Typical attack path

1. Create md RAID device with mdadm
2. Write 'inactive' to /sys/block/mdX/md/array_state
3. Write new level value to /sys/block/mdX/md/new_level
4. Trigger kernel NULL pointer dereference in md_update_sb

How to detect it

Search kernel logs and dmesg for NULL pointer dereference messages with call traces containing md_update_sb and new_level_store; correlate with sysfs writes to md array_state and new_level attributes.

• BUG: kernel NULL pointer dereference, address: 0000000000000020
• md_update_sb+0x658/0xe00
• new_level_store+0xc5/0x120
• md_attr_store+0xc9/0x1e0

What your security team should do

• Prioritize kernel upgrades on all systems using md devices
• Restrict unprivileged write access to md sysfs attributes where feasible
• Monitor kernel logs for md-related NULL pointer dereference oops