CVE-2024-58095

What it actually does

Missing read-only filesystem check before txBeginAnon in JFS extAlloc and extRecord allows modification attempts on read-only mounts, leading to errors or kernel crashes via the block write path.

Why it matters to the business

Local users or processes can trigger kernel instability or crashes on systems using JFS read-only mounts, increasing downtime risk; low exploitation likelihood but affects kernel stability in affected distributions.

How an attack unfolds

An attacker with local access triggers write operations through the JFS get_block path on a read-only mounted filesystem, reaching txBeginAnon without a prior read-only guard and causing a crash or error.

How to fix it

Update the Linux kernel to a version containing commit 15469c408af2d7a52fb186a92f2f091b0f13b1fb or later; apply distribution backports that add the read-only check before txBeginAnon in extAlloc and extRecord.

How to confirm the fix worked

Verify the applied kernel contains the read-only check in fs/jfs/jfs_extent.c before txBeginAnon; confirm no crash occurs on write attempts to read-only JFS mounts; test with kernel version checks against fixed commits.

Typical attack path

1. Mount a JFS filesystem read-only
2. Trigger block write operations via application or local process
3. Reach jfs_get_block and __block_write_begin without read-only validation
4. Call txBeginAnon on read-only mount causing failure or panic

How to detect it

Review kernel logs for JFS-related crashes or txBeginAnon call traces involving extAlloc; inspect mount options and JFS usage in system logs; correlate with local user activity attempting writes on read-only volumes.

What your security team should do

• Prioritize kernel updates on systems using JFS
• Audit for JFS read-only mounts in production workloads
• Monitor for related kernel stability issues in logging
• Apply fixes from stable kernel trees promptly given publication age