CVE-2024-49968

What it actually does

The ext4 mount logic failed to enforce that DX_HASH_SIPHASH requires the casefold feature, allowing an improperly configured filesystem to be mounted and proceed with siphash operations on a non-casefolding volume.

Why it matters to the business

Linux systems running ext4 could experience unexpected mount behavior or subsequent filesystem operations that lead to instability, data inconsistency, or exposure to follow-on kernel issues, affecting servers and containers that rely on ext4 volumes.

How an attack unfolds

An attacker supplies a crafted ext4 filesystem image (or modifies an existing volume) that sets the default hash to DX_HASH_SIPHASH while omitting the casefold feature flag. When the victim mounts the image, the missing validation allows the mount to succeed, after which siphash-based directory operations may be performed on an incompatible structure, potentially leading to crashes or further exploitation of resulting kernel states. Named campaigns involving Linux kernel flaws have targeted similar mount and hash-handling paths.

How to fix it

Upgrade to a fixed kernel containing commit 86b81d4eab1cd4c56f7447896232cf33472c2395 or later; for Rocky Linux 8 spice packages, update to 0:0.14.3-4.el8 or newer. Rebuild and redeploy any custom kernels or container images that embed the vulnerable ext4 code. After patching, test mounts of non-casefold volumes to confirm the expected mount failure occurs when siphash is configured.

How to confirm the fix worked

Verify the running kernel contains commit 86b81d4eab1cd4c56f7447896232cf33472c2395 or a backport; attempt to mount a test ext4 volume that has DX_HASH_SIPHASH set without casefold and confirm the mount is rejected with an appropriate error.

Typical attack path

1. Prepare or obtain an ext4 filesystem image with DX_HASH_SIPHASH default hash and casefold disabled
2. Deliver the image to the target system via USB, network share, container volume, or disk image
3. Trigger mount operation (manual, fstab, or automated container startup) with the default hash setting active
4. Mount succeeds due to absent validation, enabling subsequent directory operations that rely on siphash
5. Observe kernel instability, crashes, or leverage resulting state for additional attacks

How to detect it

Review kernel logs (dmesg, /var/log/kern.log, journalctl) for ext4 mount attempts that reference siphash or hash version without casefold errors; correlate with failed or successful mount events around the time of image introduction. Search for processes performing mount operations on ext4 volumes from untrusted sources. No specific post-exploitation artifacts are known.

What your security team should do

• Apply the fixed kernel version immediately on all systems using ext4, prioritizing internet-facing or multi-tenant hosts
• Audit fstab, container storage configurations, and disk images for any explicit DX_HASH_SIPHASH settings and correct them
• Add automated checks in CI/CD pipelines and image builders to reject kernels older than the fixed commit
• Monitor mount logs and kernel oops reports for ext4 hash-related failures as an interim detection measure