CVE-2023-54305

What it actually does

During ext4 filesystem umount, s_root is set to NULL while an in-flight extended attribute block expansion still attempts to dereference it, resulting in a kernel panic.

Why it matters to the business

Unexpected system crashes can occur on Linux systems using ext4 when unmount operations coincide with extended attribute changes, leading to downtime and potential data inconsistency on affected servers or devices.

How an attack unfolds

An attacker with local access triggers a filesystem unmount while simultaneously performing extended attribute operations that force ea block allocation, hitting the null s_root dereference and causing a denial-of-service crash.

How to fix it

Upgrade the Linux kernel to a version containing commit aedea161d031502a423ed1c7597754681a4f8cda or later; apply the fix that refuses ea block creation once the filesystem is unmounted.

How to confirm the fix worked

Confirm the running kernel includes the referenced commit; attempt concurrent umount and ea block operations in a test environment and verify no panic occurs.

Typical attack path

1. Obtain local execution on a system with an ext4 filesystem.
2. Initiate unmount of the target ext4 volume.
3. Concurrently issue extended attribute creation or expansion calls requiring a new ea block.
4. Trigger the race that dereferences the now-NULL s_root, inducing kernel panic.

How to detect it

Review kernel logs for oops or panic messages mentioning ext4, ea block expansion, or s_root during unmount events; correlate with audit logs showing concurrent umount and setxattr activity.

What your security team should do

• Prioritize kernel updates on all ext4-using systems within standard patching cycles.
• Monitor for kernel oops or panic logs referencing ext4 ea block handling during unmount.
• Restrict unprivileged users from performing concurrent mount and extended attribute operations where feasible.