CVE-2025-68168

What it actually does

Uninitialized waitqueue in TxBlock[0] causes invalid access to a non-static key when txEnd(0) is invoked on read-only JFS mounts, triggering lockdep warnings and kernel crashes.

Why it matters to the business

Systems using JFS filesystems mounted read-only experience unexpected kernel panics during normal mount or transaction handling, leading to downtime and potential data access loss until patched kernels are deployed.

How an attack unfolds

An attacker with the ability to trigger or influence mounting of a JFS filesystem in read-only mode can cause txBegin to return tid=0 followed by txEnd(0), which dereferences the uninitialized waitqueue and crashes the system.

How to fix it

Upgrade to a fixed kernel version such as 5.4.302 or apply the commit d6af7fce2e162ac68e85d3a11eb6ac8c35b24b64 that ensures TxBlock[0] waitqueue initialization in txInit(). Rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the fix by inspecting txInit() to verify the initialization loop includes index 0, mount a JFS volume read-only, and ensure no 'non-static key' warnings or crashes occur in txEnd.

Typical attack path

1. Identify or create a JFS filesystem image
2. Mount the filesystem read-only on a vulnerable kernel
3. Trigger txBegin returning tid=0
4. Invoke txEnd(0) to access uninitialized TxBlock[0].waitor
5. Observe kernel crash via non-static key warning

How to detect it

Review kernel logs for 'INFO: trying to register non-static key in txEnd' and related JFS transaction manager stack traces on systems mounting JFS volumes.

What your security team should do

• Prioritize patching Linux kernels on systems using JFS to the fixed versions listed
• Audit environments for JFS usage and read-only mount configurations
• Monitor kernel logs for lockdep warnings related to txEnd and waitqueues
• Test patched kernels in staging before production rollout