CVE-2025-68212

What it actually does

Uninitialized pointer dereference in statmount_string() when handling STATMOUNT_MNT_UIDMAP or STATMOUNT_MNT_GIDMAP flags, causing the kernel to write through an uninitialized offp value.

Why it matters to the business

Kernel instability or crashes on systems performing mount statistics operations, with elevated risk in container orchestration and NFS-heavy environments; widespread Linux kernel exposure increases patching urgency across fleets.

How an attack unfolds

An attacker with local access invokes statmount() with UIDMAP or GIDMAP flags, triggering the code path that leaves offp uninitialized and later dereferences it, potentially leading to memory corruption.

How to fix it

Upgrade to a kernel containing commit acfde9400e611c8d2668f1c70053c4a1d6ecfc36 or later; for affected Chainguard/Wolfi packages apply kubernetes-csi-external-attacher 4.8.0-r3 or newer.

How to confirm the fix worked

Confirm the presence of the fixing commit in the running kernel source; test that statmount() with UIDMAP/GIDMAP flags no longer produces uninitialized-pointer warnings or crashes under kernel memory debugging.

Typical attack path

1. Obtain local execution on a vulnerable Linux kernel
2. Call statmount() supplying STATMOUNT_MNT_UIDMAP or STATMOUNT_MNT_GIDMAP flags
3. Trigger the uninitialized offp dereference inside statmount_string()
4. Observe resulting kernel oops, panic, or memory corruption effects

How to detect it

Review kernel logs for oops or panic messages referencing statmount_string or uninitialized pointer dereferences during mount stat operations; correlate with processes calling statmount syscall.

What your security team should do

• Prioritize kernel updates on all systems exposing NFS or container mount APIs
• Monitor vendor advisories for backported fixes in distribution kernels
• Enable kernel hardening features such as KASAN or UBSAN in test environments to surface similar issues