CVE-2024-42299

What it actually does

Failure to synchronize log->page_mask and log->page_bits after log->page_size changes in ntfs3 log_replay leads to underflow in the bytes calculation inside read_log_page, triggering a kernel panic.

Why it matters to the business

Systems mounting NTFS volumes created on machines with different page sizes experience immediate kernel crashes and denial of service; with 21,537 downstream dependents the exposure surface across Linux distributions and embedded devices is broad.

How an attack unfolds

An attacker supplies or induces mounting of an NTFS filesystem whose log page size differs from the target's PAGE_SIZE; during log replay the mismatched mask and bits produce a negative value that panics the kernel before any further processing occurs.

How to fix it

Upgrade the Linux kernel to a version containing commit 0484adcb5fbcadd9ba0fd4485c42630f72e97da9 or later stable releases; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit; attempt to mount an NTFS volume created on a system with a different PAGE_SIZE and verify no panic occurs.

Typical attack path

1. Obtain or craft an NTFS volume whose log page size differs from the target kernel's PAGE_SIZE
2. Cause the target to mount the volume (local device, loopback, or network share)
3. Trigger log_replay() followed by read_log_page() to induce the negative-value panic

How to detect it

Search kernel logs and crash dumps for ntfs3, log_replay, read_log_page, and references to negative page-size calculations or page mask mismatches.

What your security team should do

• Apply kernel updates containing the fix as soon as packages are available
• Restrict mounting of untrusted NTFS volumes until patches are deployed
• Include ntfs3 mount operations in crash-log monitoring and alerting