CVE-2025-38701

What it actually does

A maliciously crafted ext4 filesystem image with an inode having the INLINE_DATA_FL flag set but lacking the required system.data extended attribute triggers a BUG_ON in ext4_update_inline_data (and similar paths in ext4_create_inline_data and ext4_inline_data_truncate), causing a kernel panic instead of graceful corruption handling.

Why it matters to the business

Systems relying on ext4 filesystems face denial-of-service risk from local kernel crashes when processing untrusted or fuzzed images, leading to unplanned downtime, potential data inconsistency during recovery, and operational disruption on servers or containers using affected kernels.

How an attack unfolds

An attacker prepares a specially fuzzed ext4 image containing an inode with inconsistent INLINE_DATA_FL metadata, then causes the target system to mount or access the image (via local access or container image), resulting in the kernel hitting the BUG_ON and crashing. No widespread active exploitation or ransomware use is associated with this issue.

How to fix it

Upgrade affected Linux kernels to a version containing commit 8085a7324d8ec448c4a764af7853e19bbd64e17a or later; for MinimOS packages update mysql-8.4, mysql-8.4-dev, mysql-8.4-client and related entries to version 8.4.3-r0 or newer. Reboot systems after kernel updates and validate ext4 images before mounting untrusted filesystems.

How to confirm the fix worked

Verify kernel source or package version includes the referenced commit or fixed package versions; attempt to mount a test image with the inconsistent inline data flag and confirm EXT4_ERROR_INODE is emitted instead of a BUG/panic; review dmesg or kernel logs for absence of the previous BUG_ON path.

Typical attack path

1. Craft malicious ext4 filesystem image with inconsistent INLINE_DATA_FL inode metadata
2. Place the image in a location accessible to the target (local filesystem, container image, or removable media)
3. Trigger mount or access operation on the image by a privileged process or user
4. Kernel executes ext4 inline data handling code and hits BUG_ON, causing panic

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for ext4-related BUG or panic messages referencing inline_data or ext4_update_inline_data; look for unexpected system reboots correlated with ext4 mount activity; monitor for EXT4_ERROR_INODE messages after patching to confirm graceful handling.

• ext4_update_inline_data
• INLINE_DATA_FL
• system.data
• EXT4_ERROR_INODE

What your security team should do

• Prioritize kernel and package upgrades on all ext4-using systems within standard change windows
• Restrict mounting of untrusted ext4 images to hardened or isolated environments
• Enable filesystem integrity checks and monitor for ext4 corruption reports in logs
• Review container and image build pipelines to ensure they use updated base kernels