CVE-2021-47113

What it actually does

A failed second inode reference insertion during btrfs rename_exchange leaves the first reference dangling, resulting in filesystem metadata inconsistency and potential corruption.

Why it matters to the business

Systems using btrfs may experience unexpected filesystem corruption or data inaccessibility after rename operations encounter errors, increasing downtime and recovery costs in container and Linux environments.

How an attack unfolds

An attacker with local access triggers a rename_exchange syscall on a btrfs filesystem under conditions where the second inode ref insert fails (via crafted operations or error injection), leaving dangling references and corrupting the filesystem without triggering an abort.

How to fix it

Upgrade affected packages to the listed fixed versions: oci-systemd-hook to 1:0.1.15-2.git2d0b8a3.module_el8.5.0+119+9a9ec082, oci-umount to 2:2.3.4-2.git87f9237.module_el8.5.0+119+9a9ec082, fuse-overlayfs to 0.3-5.module_el8.3.0+2044+12421f43, criu to 3.12-9.module_el8.4.0+2496+12421f43, crit to 3.12-9.module_el8.3.0+2044+12421f43, python3-criu to 3.12-9.module_el8.3.0+2044+12421f43, slirp4netns to 0.1-5.dev.gitc4e1bc5.module_el8.3.0+2044+12421f43, containernetworking-plugins to 0.7.4-4.git9ebe139.module_el8.3.0+2044+12421f43, container-selinux to 2:2.124.0-1.gitf958d0c.module_el8.3.0+2044+12421f43, buildah to 1.5-8.gite94b4f9.module_el8.5.0+119+9a9ec082, containers-common to 1:0.1.32-6.git1715c90.module_el8.4.0+2478+12421f43, runc to 1.0.0-56.rc5.dev.git2abd837.module_el8.3.0+2044+12421f43, skopeo to 1:0.1.32-6.git1715c90.module_el8.4.0+2496+12421f43. Reboot or restart affected container services after upgrade.

How to confirm the fix worked

Verify package versions match the fixed releases, run btrfs filesystem check on volumes, and confirm no dangling inode references via kernel logs or fsck after rename operations.

Typical attack path

1. Obtain local access to a system using btrfs
2. Perform or induce a rename_exchange operation
3. Force failure of the second inode reference insertion
4. Observe resulting filesystem corruption from the dangling reference

How to detect it

Review kernel logs for btrfs abort messages or rename_exchange failures, inspect filesystem metadata for dangling inode references using btrfs utilities, and correlate with application-level rename errors in container workloads.

What your security team should do

• Prioritize patching all listed container packages to the specified fixed versions
• Monitor for btrfs-related kernel errors in system logs
• Test rename operations in staging environments using btrfs before production rollout