Skip to main content

Linux Kernel CVE-2025-68168

HIGH
2025-12-16 416baaa9-dc9f-4396-8d5f-8c081fb06d67
7.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
5.5 MEDIUM

Local trigger via a read-only JFS mount (AV:L, PR:L for mount capability); the described impact is a kernel crash only, so C:N/I:N/A:H rather than full CIA.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
7.1 MEDIUM
qualitative

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 07:30 vuln.today
CVE Published
Dec 16, 2025 - 14:15 cve.org
HIGH 7.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

jfs: fix uninitialized waitqueue in transaction manager

The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems.

When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0.

This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEnd

Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit().

AnalysisAI

Denial-of-service in the Linux kernel JFS filesystem driver lets a local low-privileged actor crash the system by mounting a JFS volume read-only. Because txInit() started its waitqueue-initialization loop at index 1, TxBlock[0].waitor is left uninitialized; a read-only mount returns tid=0 and the subsequent txEnd(0) dereferences that uninitialized waitqueue, triggering a lockdep 'non-static key' warning and a kernel crash. EPSS is low (0.18%, 8th percentile), there is no public exploit identified at time of analysis, and it is not in CISA KEV - impact is a crash rather than code execution.

Technical ContextAI

The affected component is JFS (Journaled File System), an IBM-originated on-disk filesystem supported as an optional Linux kernel module. JFS uses a transaction manager with a static array of transaction blocks (TxBlock), each carrying a wait queue (waitor) used to serialize transaction lifecycle events. During initialization txInit() must set up every block's waitqueue, but the loop iterated from index 1, leaving TxBlock[0] uninitialized. On a read-only mount txBegin() returns tid=0 as a sentinel meaning 'no transaction'; txEnd(0) nonetheless resolves tid_to_tblock(0) and operates on the never-initialized waitqueue. No CWE was supplied by the source, but the root cause is best classified as use of an uninitialized resource / improper initialization (CWE-908/CWE-665), surfaced by the kernel lockdep subsystem as a 'non-static key' registration on an uninitialized lock.

Affected ProductsAI

The Linux kernel's JFS filesystem driver (fs/jfs transaction manager, txInit/txEnd) is affected. No CPE strings or explicit version ranges were provided in the input, and the source records CWE as N/A; the fix is distributed as eight stable-tree commits at git.kernel.org (038861414ab3, 2a9575a37218, 300b072df726, 8cae9cf23e0b, a2aa97cde985, cbf2f527ae4c, d2dd7ca05a11, d6af7fce2e16), indicating backports across multiple maintained stable branches rather than a single release. Exact vulnerable-to-fixed version boundaries are not stated in the data and should be confirmed against the corresponding kernel.org stable changelogs.

RemediationAI

Upstream fix available (commit); the patch corrects txInit() to initialize the waitqueue for all transaction blocks including TxBlock[0]. Apply the kernel update from your distribution that incorporates the stable commits referenced at git.kernel.org (e.g. d6af7fce2e162ac68e85d3a11eb6ac8c35b24b64 and the parallel backports 038861414ab3, 2a9575a372182, 300b072df726, 8cae9cf23e0b, a2aa97cde985, cbf2f527ae4c, d2dd7ca05a11); a released patched version was not independently confirmed from the input, so map the commit to your distro's advisory before deployment. Where patching must be deferred, the concrete compensating control is to prevent JFS volumes from being mounted: blacklist the jfs module (e.g. 'install jfs /bin/true' via modprobe) if JFS is not required, and restrict/disable automatic mounting of removable or user-supplied media so untrusted JFS volumes cannot be mounted read-only by low-privileged users. Trade-off: blacklisting jfs breaks any legitimate JFS usage, and disabling automount reduces convenience for removable storage.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.95 Container suse/sl-micro/6.1/base-os-container:2.2.1-5.80 Image SL-Micro Image SL-Micro-Azure Image SL-Micro-BYOS-Azure Image SL-Micro-BYOS-EC2 Image SL-Micro-BYOS-GCE Image SL-Micro-EC2 Image SLE-Micro Image SLE-Micro-Azure Image SLE-Micro-BYOS Image SLE-Micro-BYOS-Azure Image SLE-Micro-BYOS-EC2 Image SLE-Micro-BYOS-GCE Image SLE-Micro-EC2 Image SLE-Micro-GCE Image SUSE-Multi-Linux-Manager-Proxy-BYOS-Azure Image SUSE-Multi-Linux-Manager-Proxy-BYOS-EC2 Image SUSE-Multi-Linux-Manager-Proxy-BYOS-GCE Image SUSE-Multi-Linux-Manager-Server-Azure-llc Image SUSE-Multi-Linux-Manager-Server-Azure-ltd Image SUSE-Multi-Linux-Manager-Server-BYOS-Azure Image SUSE-Multi-Linux-Manager-Server-BYOS-EC2 Image SUSE-Multi-Linux-Manager-Server-BYOS-GCE Image SUSE-Multi-Linux-Manager-Server-EC2-llc Image SUSE-Multi-Linux-Manager-Server-EC2-ltd Affected
Container suse/sl-micro/6.0/kvm-os-container:2.1.3-6.115 Container suse/sl-micro/6.1/kvm-os-container:2.2.1-5.83 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.146 Container suse/sl-micro/6.1/rt-os-container:2.2.1-5.91 Affected
Image SLES15-SP6-SAP-Azure-3P Image SLES15-SP6-SAP-Azure-LI-BYOS Image SLES15-SP6-SAP-Azure-LI-BYOS-Production Image SLES15-SP6-SAP-Azure-VLI-BYOS Image SLES15-SP6-SAP-Azure-VLI-BYOS-Production Image SLES15-SP6-SAP-BYOS Image SLES15-SP6-SAP-BYOS-Azure Image SLES15-SP6-SAP-BYOS-EC2 Image SLES15-SP6-SAP-BYOS-GCE Image SLES15-SP6-SAP-Hardened Image SLES15-SP6-SAP-Hardened-Azure Image SLES15-SP6-SAP-Hardened-BYOS Image SLES15-SP6-SAP-Hardened-BYOS-Azure Image SLES15-SP6-SAP-Hardened-BYOS-EC2 Image SLES15-SP6-SAP-Hardened-BYOS-GCE Image SLES15-SP6-SAP-Hardened-EC2 Image SLES15-SP6-SAP-Hardened-GCE Affected
Image SLES15-SP6 Image SLES15-SP6-BYOS Image SLES15-SP6-BYOS-Azure Image SLES15-SP6-BYOS-EC2 Image SLES15-SP6-BYOS-GCE Image SLES15-SP6-CHOST-BYOS Image SLES15-SP6-CHOST-BYOS-Aliyun Image SLES15-SP6-CHOST-BYOS-Azure Image SLES15-SP6-CHOST-BYOS-EC2 Image SLES15-SP6-CHOST-BYOS-GCE Image SLES15-SP6-CHOST-BYOS-GDC Image SLES15-SP6-CHOST-BYOS-SAP-CCloud Image SLES15-SP6-EC2 Image SLES15-SP6-EC2-ECS-HVM Image SLES15-SP6-GCE Image SLES15-SP6-HPC-BYOS Image SLES15-SP6-HPC-BYOS-Azure Image SLES15-SP6-HPC-BYOS-EC2 Image SLES15-SP6-HPC-BYOS-GCE Image SLES15-SP6-HPC-EC2 Image SLES15-SP6-HPC-GCE Image SLES15-SP6-Hardened-BYOS Image SLES15-SP6-Hardened-BYOS-Azure Image SLES15-SP6-Hardened-BYOS-EC2 Image SLES15-SP6-Hardened-BYOS-GCE Image SLES15-SP6-SAP Image SLES15-SP6-SAP-Azure Image SLES15-SP6-SAP-EC2 Image SLES15-SP6-SAP-GCE Image SLES15-SP6-SAPCAL Image SLES15-SP6-SAPCAL-Azure Image SLES15-SP6-SAPCAL-EC2 Image SLES15-SP6-SAPCAL-GCE Affected

Share

CVE-2025-68168 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy