CVE-2025-38059

What it actually does

NULL pointer dereference in btrfs_lookup_csums_bitmap during read-only scrub when the csum tree root is absent due to the rescue=idatacsums mount option, because scrub omits the NO_DATA_CSUMS fs-state check before calling btrfs_search_slot.

Why it matters to the business

Kernel panic and system crash on Linux systems using btrfs with the rescue mount option when scrub is invoked, causing denial of service and potential data unavailability.

How an attack unfolds

An attacker with local access mounts a btrfs filesystem using rescue=idatacsums to skip csum tree loading, then triggers a read-only scrub via ioctl; the missing root pointer leads directly to the kernel crash without any further exploitation steps.

How to fix it

Upgrade the Linux kernel to a version containing commit 50d0de59f66cbe6d597481e099bf1c70fd07e0a9 or later; avoid using rescue=idatacsums with scrub until patched.

How to confirm the fix worked

Confirm kernel version includes the fix commit; test that scrub completes without crash on a rescue-mounted btrfs volume; verify extent and csum tree roots are checked before search operations.

Typical attack path

1. Mount btrfs volume with rescue=idatacsums option
2. Invoke btrfs scrub start or equivalent ioctl on the device
3. Scrub code path reaches scrub_find_fill_first_stripe without csum tree validation
4. NULL dereference occurs in btrfs_lookup_csums_bitmap

How to detect it

Review kernel logs for NULL pointer dereference traces mentioning btrfs_lookup_csums_bitmap, scrub_find_fill_first_stripe, and rescue mount options; correlate with ioctl calls to btrfs.

What your security team should do

• Apply kernel update containing the referenced commit immediately on all btrfs systems
• Audit for use of rescue mount options in production environments
• Disable or restrict scrub capabilities for unprivileged users until patched
• Monitor for btrfs-related kernel panics in system logs