CVE-2025-68820

What it actually does

Null pointer dereference in ext4_xattr_inode_dec_ref_all() after ext4_get_inode_loc() fails and leaves iloc.bh as NULL, causing ext4_raw_inode() to crash the kernel.

Why it matters to the business

Unexpected system crashes or denial of service on Linux systems using ext4 filesystems with extended attributes, potentially disrupting operations on servers or devices; high ecosystem prevalence increases exposure for organizations running unpatched kernels.

How an attack unfolds

An attacker with local access or ability to trigger filesystem corruption can cause ext4_get_inode_loc() to fail (e.g., via -EFSCORRUPTED), then invoke xattr reference decrement paths that blindly dereference the NULL buffer head, leading to kernel panic.

How to fix it

Upgrade Linux kernel to version 5.10.248 or later, or apply commit b72a3476f0c97d02f63a6e9fff127348d55436f6 in the stable tree; rebuild and reboot affected systems with the fixed kernel.

How to confirm the fix worked

Verify running kernel version against fixed releases; inspect ext4 source for presence of error checks around ext4_get_inode_loc() and iloc.bh before xattr reference handling; test with corrupted filesystem images that previously triggered the path.

Typical attack path

1. Gain local access or control filesystem metadata to induce ext4_get_inode_loc() failure
2. Trigger xattr operations that call ext4_xattr_inode_dec_ref_all() without checking for prior errors
3. Cause null dereference in ext4_raw_inode() resulting in kernel crash or potential memory corruption

How to detect it

Review kernel logs (dmesg, /var/log/kern.log, journalctl) for null pointer dereference oops mentioning ext4_raw_inode, ext4_xattr_inode_dec_ref_all, or ext4_get_inode_loc failures; correlate with recent xattr or inode operations on ext4 mounts.

• ext4_raw_inode
• ext4_xattr_inode_dec_ref_all
• ext4_get_inode_loc.*EFSCORRUPTED
• kernel: BUG: unable to handle kernel NULL pointer dereference

What your security team should do

• Prioritize kernel upgrades on all production ext4 systems within standard patch windows
• Monitor for kernel oops/panic reports involving ext4 xattr functions
• Consider filesystem integrity checks (fsck) on high-risk volumes to reduce trigger conditions