CVE-2022-50864

What it actually does

Corrupted s_log_block_size field in nilfs2 superblock triggers shift-out-of-bounds during init_nilfs and load_nilfs, producing UBSAN warning and optional kernel panic.

Why it matters to the business

Mounting a malicious or corrupted nilfs2 filesystem can crash the system, causing denial of service and potential data unavailability on affected Linux kernels.

How an attack unfolds

An attacker crafts a nilfs2 filesystem image with an excessively large s_log_block_size value in the superblock and supplies it to a victim system; when the kernel attempts to mount the image, the oversized exponent causes the shift operation to fail bounds checks.

How to fix it

Upgrade the Linux kernel to a version containing commit ec93b5430ec0f60877a5388bb023d60624f9ab9f or later that adds the sanity-checked block-size helper.

How to confirm the fix worked

Confirm kernel version includes the referenced commit; attempt to mount a test image containing a large s_log_block_size value and verify no shift-out-of-bounds warning or panic occurs.

Typical attack path

1. Prepare malicious nilfs2 image with oversized s_log_block_size in superblock
2. Trick or force target system to mount the image via local access or network share
3. Kernel executes init_nilfs or load_nilfs and performs unchecked shift
4. UBSAN triggers warning; panic_on_warn setting causes kernel panic

How to detect it

Review kernel logs for UBSAN shift-out-of-bounds messages mentioning nilfs2 or init_nilfs; inspect mount attempts of nilfs2 volumes from untrusted sources.

What your security team should do

• Apply the kernel update containing ec93b5430ec0f60877a5388bb023d60624f9ab9f immediately on all systems using nilfs2
• Disable automatic mounting of untrusted nilfs2 volumes until patched
• Monitor for kernel panics referencing nilfs_mount or init_nilfs during filesystem operations