CVE-2023-3397

What it actually does

Race condition between lmLogClose and txEnd in JFS allows concurrent execution in different threads to trigger kernel crash or leak internal kernel memory to a local user.

Why it matters to the business

Linux systems using the JFS filesystem may experience unexpected crashes or exposure of sensitive kernel data, leading to operational downtime and potential follow-on attacks.

How an attack unfolds

A local attacker with normal privileges performs filesystem operations that cause lmLogClose and txEnd to race, resulting in a crash or memory disclosure without needing elevated rights.

How to fix it

Upgrade the Linux kernel to a version containing the fix for the JFS race condition; rebuild and reboot affected systems; consider disabling JFS if unused.

How to confirm the fix worked

Verify the running kernel version is newer than the vulnerable release, review JFS-related source changes in the changelog, and test concurrent filesystem workloads for stability.

Typical attack path

1. Obtain local shell access as a normal user
2. Mount or access a JFS filesystem
3. Trigger concurrent log-close and transaction-end operations via crafted I/O or filesystem calls
4. Observe kernel oops/panic or extract leaked memory contents

How to detect it

Search kernel logs and crash dumps for JFS transaction or logging errors around the time of unexpected reboots or oops messages; inspect for anomalous memory disclosure patterns in process dumps.

What your security team should do

• Apply the kernel update as soon as a fixed package is available from the distribution
• Audit systems for JFS usage and migrate to supported filesystems where feasible
• Monitor kernel logs for JFS-related oops and panics
• Restrict local user access on systems still running vulnerable kernels