CVE-2021-47145

What it actually does

Improper error handling in btrfs tree-log recovery code replaces legitimate return of -EIO (or other errors) from btrfs_search_slot with a BUG_ON, triggering a kernel panic during log replay on mount.

Why it matters to the business

Unexpected system crashes during filesystem mount or recovery can cause downtime, data unavailability, and potential loss of in-flight writes on affected Linux systems; low exploitability and stable low EPSS reduce immediate risk, though the issue has been public for over two years.

How an attack unfolds

An attacker with the ability to present a specially crafted or corrupted btrfs filesystem image (or trigger I/O errors via hardware fault or error injection) causes btrfs_recover_log_trees to hit the buggy error path in link_to_fixup_dir during mount, resulting in denial of service via kernel panic; no named threat actors or ransomware campaigns are associated.

How to fix it

Upgrade binutils-devel on AlmaLinux 8 to version 2.30-108.el8_5.1 or later; apply the corresponding kernel package update that contains the btrfs fix; test mounts of potentially affected volumes after patching.

How to confirm the fix worked

Confirm the running kernel contains the patch by checking the btrfs/tree-log.c source or kernel version string; attempt to mount a volume that previously triggered the error path and verify it now returns a clean error instead of panicking.

Typical attack path

1. Prepare or obtain a btrfs volume whose log tree triggers an error return from btrfs_search_slot during replay
2. Initiate mount of the volume (local or via malicious image supplied to a victim)
3. Walk log tree calls replay_one_buffer which invokes the buggy function
4. BUG_ON fires, kernel panics

How to detect it

Review kernel logs for the exact BUG line 'kernel BUG at fs/btrfs/tree-log.c:1862' and the call trace containing replay_one_buffer, walk_log_tree, and btrfs_recover_log_trees during mount attempts; correlate with failed mount syscalls on btrfs volumes.

What your security team should do

• Prioritize patching systems that mount untrusted btrfs images or perform frequent log recovery
• Update to the exact fixed package version listed for AlmaLinux 8
• Monitor mount operations on btrfs volumes for unexpected panics until patches are deployed