CVE-2025-68356

What it actually does

The vulnerability allows new inodes in GFS2 to inherit a gfp_mask containing __GFP_FS, permitting memory reclaim to recurse into filesystem code during transactions such as gfs2_unstuff_dinode(), leading to stack exhaustion or deadlock.

Why it matters to the business

Systems relying on GFS2 filesystems face elevated risk of crashes or hangs under memory pressure, resulting in storage service disruption and potential downtime in clustered or high-availability environments; widespread kernel usage increases exposure across many deployments.

How an attack unfolds

An attacker with local access induces memory pressure while GFS2 performs inode allocation or transaction operations, causing reclaim paths to re-enter filesystem code and trigger deadlock or stack overflow.

How to fix it

Apply the upstream fix (commit edb2b255618621dc83d0ec23150e16b2c697077f) or later stable kernels; for listed Chainguard images update to version 3.6.5-r2 or newer.

How to confirm the fix worked

Confirm kernel source contains the gfp_mask adjustment that clears __GFP_FS from inode address spaces, or verify running kernel version includes the referenced commit; test under memory pressure with GFS2 workloads to ensure no recursion occurs.

Typical attack path

1. Obtain local code execution on a host with GFS2 mounted
2. Trigger memory pressure via allocation-heavy workloads or other means
3. Invoke GFS2 operations that allocate inodes or call unstuff_dinode inside transactions
4. Allow reclaim to recurse and exhaust stack or deadlock

How to detect it

Examine kernel logs and dmesg for GFS2 transaction or reclaim-related stack traces, panics, or warnings under memory pressure conditions; correlate with workload patterns that allocate inodes.

What your security team should do

• Prioritize kernel upgrades on all hosts using GFS2 within the next patch cycle
• Review and test GFS2-dependent workloads after applying updates
• Monitor memory usage patterns on GFS2 systems until patches are deployed