CVE-2025-38337

What it actually does

Null pointer dereference and data race on jh->b_modified in jbd2_journal_dirty_metadata due to missing is_handle_aborted check and missing READ/WRITE_ONCE annotations, allowing concurrent writers to corrupt transaction state in the ext4/jbd2 journaling path.

Why it matters to the business

Unexpected kernel crashes or filesystem metadata corruption on Linux systems using ext4, leading to downtime, potential data loss, and operational disruption; high ecosystem prevalence across server and embedded deployments increases exposure surface.

How an attack unfolds

A local attacker triggers concurrent inode dirty operations (ext4_mark_inode_dirty paths) while a handle is being aborted; the missing abort check allows dereference of a NULL transaction pointer and the unprotected b_modified field permits a data race that an advanced spyware campaign or privilege-escalation toolkit could weaponize for denial-of-service or further kernel memory corruption.

How to fix it

Upgrade to a fixed kernel version: linux-lts (Alpaquita:stream) 6.6.58-r0 or 6.12.41-r0, linux-lts (Alpaquita:23) 6.1.74-r0, or mainline commit 5c1a34ff5b0bfdfd2f9343aa9b08d25df618bac5. Reboot after package installation; apply vendor kernel updates as soon as available given the 474 days since publication and rising EPSS trend.

How to confirm the fix worked

Verify the running kernel contains the commit or package version listed above; inspect fs/jbd2/transaction.c for the is_handle_aborted guard and READ/WRITE_ONCE annotations on b_modified; run KCSAN or syzkaller workloads that previously triggered the race to confirm absence of reports.

Typical attack path

1. Obtain local code execution on an affected Linux kernel
2. Open multiple files or trigger inode updates that call ext4_dirty_inode concurrently
3. Force a transaction abort in one thread while the second thread executes jbd2_journal_dirty_metadata
4. Trigger the NULL dereference or race on b_modified to induce kernel panic or memory corruption

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for KCSAN reports mentioning jbd2_journal_dirty_metadata or ext4_mark_iloc_dirty; monitor for unexpected kernel oops or null-pointer dereference stack traces involving transaction.c:1512 or :1556; correlate with process activity that performs heavy ext4 inode updates.

What your security team should do

• Prioritize patching all production Linux systems within the next maintenance window due to rising EPSS and listed threat-actor interest
• Enable kernel live-patching where supported to reduce reboot impact
• Add kernel update automation and monitoring for jbd2/ext4 related panics in observability platforms
• Review and restrict untrusted local code execution surfaces on multi-tenant or container hosts