CVE-2023-53323

What it actually does

Triggers BUG_ON(maxblocks == 0) inside ext2_get_blocks during dax_zero_range called from ext2_setsize when the length passed to truncate is already page-aligned (including zero), because PAGE_ALIGN returns the input unchanged and dax_zero_range then passes zero blocks to iomap_begin.

Why it matters to the business

Systems using ext2 on DAX-enabled persistent memory can experience immediate kernel panic and crash during routine file truncation operations, leading to service interruption and potential data loss on affected hosts until reboot.

How an attack unfolds

An attacker with write access to a DAX-mounted ext2 filesystem on pmem creates a small file, then issues a truncate-to-zero operation that reaches ext2_setsize -> dax_zero_range with a page-aligned length of zero, causing the kernel to hit the BUG_ON and panic.

How to fix it

Upgrade the Linux kernel to commit 9e54fd14bd143c261e52fde74355e85e9526c58c or later. For Debian-packaged bacula on versions 11-14 apply update to 2.4.0-1. Disable DAX on ext2 mounts until patched if immediate update is not possible.

How to confirm the fix worked

Confirm kernel version contains 9e54fd14bd143c261e52fde74355e85e9526c58c; reproduce the dd+truncate sequence on a test ext2/DAX mount and verify no BUG or panic occurs; inspect ext2_setsize and dax_zero_range paths for the added dax_truncate_page guard.

Typical attack path

1. Mount ext2 filesystem with DAX on pmem device
2. Create file via dd if=/dev/zero of=file count=1 bs=512
3. Execute truncate -s 0 file
4. Kernel executes ext2_setsize -> dax_zero_range -> ext2_iomap_begin -> ext2_get_blocks with maxblocks=0
5. BUG_ON triggers and system panics

How to detect it

Search kernel logs, dmesg, and journalctl for the strings 'kernel BUG at fs/ext2/inode.c:637', 'ext2_get_blocks.constprop.0', 'invalid opcode', and the call trace containing dax_zero_range, ext2_setsize, and ext2_iomap_begin around the time of unexpected reboots or panics.

• kernel BUG at fs/ext2/inode.c:637
• ext2_get_blocks.constprop.0+0x524/0x610
• invalid opcode: 0000 [#1] PREEMPT SMP PTI
• Call Trace: ext2_iomap_begin dax_zero_range ext2_setsize
• EXT2-fs (pmem0): DAX enabled

What your security team should do

• Prioritize kernel upgrade on any hosts exposing ext2/DAX mounts
• Audit for ext2 filesystems mounted with -o dax and migrate to ext4 or disable DAX where feasible
• Add kernel oops and BUG signature monitoring to detect attempted exploitation
• Review and restrict unprivileged write access to pmem-backed ext2 mounts