CVE-2023-54069

What it actually does

Integer overflow in ext4_mb_new_inode_pa() when computing the end of an ext4_free_extent causes new_bex_end to wrap to zero, triggering a BUG_ON in the best-extent adjustment path of the block allocator.

Why it matters to the business

Unprivileged local users can crash Linux systems running ext4, leading to denial of service, unexpected reboots, and potential loss of in-flight writes or filesystem consistency on servers and workstations that rely on ext4.

How an attack unfolds

An attacker with local access crafts a sequence of fallocate operations that position an extent near the 32-bit logical block limit, then triggers allocation paths that force the best-extent adjustment logic to evaluate the overflowing end value, causing the kernel to hit the BUG_ON and panic.

How to fix it

Upgrade the Linux kernel to a fixed version (5.4.260 or later stable releases containing commit 83ecffd40c65844a73c2e93d7c841455786605ac). Reboot after installing the updated kernel package. Where live patching is available, apply the vendor's kernel live patch for the affected distribution.

How to confirm the fix worked

Confirm the running kernel version is at or above the fixed release listed for the distribution; attempt to reproduce the original reproducer steps in a test environment and verify the BUG_ON no longer occurs; review kernel changelog or git history for the extent_logical_end refactor.

Typical attack path

1. Obtain local shell or execute code on a system with an ext4 filesystem
2. Create or open a large file and issue fallocate calls that set fe_logical near UINT_MAX minus a small length
3. Trigger repeated block allocations via fsstress or direct I/O that exercise ext4_mb_try_best_found and ext4_mb_new_inode_pa
4. Cause the overflow condition that sets new_bex_end to zero and hits the BUG_ON

How to detect it

Search kernel logs for the string "kernel BUG at fs/ext4/mballoc.c:5116" or the call trace containing ext4_mb_new_inode_pa, ext4_mb_use_best_found, and ext4_mb_try_best_found around the time of unexpected reboots; examine audit logs for sequences of fallocate and fsstress activity on ext4 mounts immediately preceding crashes.

What your security team should do

• Prioritize patching of internet-facing or multi-tenant Linux systems that use ext4 within the next maintenance window
• Restrict unprivileged local access on systems where immediate patching is not feasible
• Monitor vendor advisories for backported fixes in LTS kernels still in use