CVE-2024-47700 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
ext4: check stripe size compatibility on remount as well
We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0.
Fix that by adding the check in remount path as well.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 01/19/2026
The vulnerability described in CVE-2024-47700 affects the Linux kernel's ext4 file system implementation and represents a critical inconsistency in how stripe size parameters are validated during file system operations. This issue stems from an incomplete validation mechanism that only checks stripe size compatibility during initial superblock filling but fails to perform the same validation during remount operations. The root cause lies in the __ext4_fill_super function which correctly disables stripe size when it is not a multiple of the cluster ratio, yet this essential validation is omitted in the remount path, creating a potential security and stability risk.
The technical flaw manifests when an ext4 file system undergoes a remount operation with incompatible stripe size parameters. During normal mount operations, the kernel properly validates that stripe sizes are multiples of the cluster ratio and disables stripe functionality when this condition is not met. However, during remount operations, this validation is bypassed, allowing stripe size values to become smaller than the cluster ratio. This creates an arithmetic edge case where the EXT4_B2C calculation with sbi->s_stripe parameter can result in a division by zero scenario, as the cluster ratio calculation becomes invalid when stripe size is effectively zero or improperly scaled.
This vulnerability directly impacts system stability and can potentially enable privilege escalation or denial of service conditions within the kernel's file system subsystem. The operational impact extends beyond simple file system corruption, as the division by zero condition can cause kernel panics or unpredictable behavior that may allow malicious actors to exploit the system. According to CWE classification, this represents a weakness in the form of improper validation of input parameters, specifically CWE-252, and potentially CWE-129 for insufficient boundary checking. The vulnerability aligns with ATT&CK technique T1068 which involves exploiting local privilege escalation opportunities, and T1490 for creating or manipulating system resources.
The fix implemented addresses this by extending the validation logic to include the remount path, ensuring that stripe size compatibility checks occur consistently regardless of whether the file system is being mounted for the first time or remounted. This remediation maintains kernel stability by preventing invalid stripe size configurations that could lead to arithmetic errors or system crashes. The solution follows best practices for kernel security by ensuring consistent validation across all file system operation paths and prevents potential exploitation through malformed remount parameters that could be used to trigger the division by zero condition. Organizations should prioritize applying this kernel patch to prevent potential system instability or security compromise, particularly in environments where ext4 file systems are actively remounted or where file system parameter manipulation could occur through unprivileged user access.