CVE-2024-53131

What it actually does

Null pointer dereference in nilfs2 when block:block_touch_buffer tracepoint triggers touch_buffer() before bh->b_bdev is initialized in __nilfs_get_folio_block.

Why it matters to the business

Local users or diagnostic tools can trigger kernel crashes on systems using the nilfs2 filesystem, leading to denial of service and potential data loss or downtime until patched.

How an attack unfolds

An attacker with local access enables the block tracepoint, performs nilfs2 operations that reach __nilfs_get_folio_block, and causes the dereference inside touch_buffer before the block_device pointer is set.

How to fix it

Update the Linux kernel to commit 085556bf8c70e2629e02e79268dac3016a08b8bf or later; apply listed package fixes for affected distributions such as the provided ffmpeg and libav updates on Ubuntu.

How to confirm the fix worked

Confirm kernel commit presence via git log or package version; re-test with tracepoint enabled on nilfs2 to ensure no dereference occurs.

Typical attack path

1. Enable block:block_touch_buffer tracepoint via tracing subsystem
2. Mount or access a nilfs2 filesystem
3. Invoke code paths calling __nilfs_get_folio_block
4. Trigger null dereference resulting in oops or panic

How to detect it

Inspect kernel logs for oops/panic messages referencing nilfs2, touch_buffer, or block tracepoints; look for tracepoint activation events followed by crashes.

What your security team should do

• Apply kernel updates immediately on nilfs2 systems
• Disable unnecessary block tracepoints until patched
• Monitor for kernel crashes related to nilfs2
• Review filesystem usage and migrate off nilfs2 if updates cannot be applied promptly