A patch landed in the Linux kernel’s stable trees on December 24, 2025, fixing a subtle but dangerous memory allocation mistake in the GFS2 clustered filesystem. The vulnerability, tracked as CVE-2025-68356, allowed memory reclaim operations to re-enter filesystem transaction code, creating a perfect storm for deadlocks and kernel stack exhaustion. The fix is surgical: it strips a single flag from inode address-space mappings, and every administrator running GFS2 in production should treat this as an urgent availability issue.

The Fix in Plain English

When the Linux kernel runs short on memory, it triggers reclaim routines to free pages. On a GFS2 filesystem, those reclaim paths could call back into GFS2 code that was already holding a transaction lock. The result was a recursive death spiral—two pieces of kernel code waiting on each other, or the kernel stack simply blowing past its limit.

The root cause? A single flag, __GFP_FS, was inadvertently left set in the gfp_mask used when creating new inode address spaces. That flag tells the memory allocator, “It’s okay to call back into filesystem code while satisfying this allocation.” In the context of a transaction, that permission is disastrous.

The upstream fix changes one line of code: it clears __GFP_FS from the inode mapping’s GFP mask, so page-cache allocations inside GFS2 can no longer trigger filesystem re-entry. The patch also adjusts the mask to avoid the opposite mistake—being too restrictive—by starting from the default mask and only removing the dangerous bit. Other GFS2 address spaces, like metadata and resource groups, already used GFP_NOFS to explicitly disallow this, so the inode mapping was the odd one out.

Who’s Actually Affected?

This is not a drive-by remote exploit. An attacker needs local access and the ability to trigger the pathological allocation pattern. But for the right kind of server, the impact is a hard hang or kernel panic.

  • Cluster and shared-storage admins: If you manage a GFS2 cluster—whether on bare metal, VMs, or cloud instances—you are in the blast radius. Multi-tenant platforms where one tenant can stress the filesystem are especially exposed.
  • Cloud and virtual appliance operators: Many cloud-targeted kernels (including Azure’s) ship GFS2 support by default. Don’t assume you’re safe just because you didn’t explicitly enable it. Check your kernel config.
  • Everyone else: Desktop systems, single-disk servers, and anything not mounting GFS2 are not directly affected. But if your distribution’s generic kernel includes the module, a future update might pull in the fix anyway—no harm in applying it.

The trigger was reproducible in kernel test suites. The fix’s commit message references xfstest/generic/273 as a test case that exercised the exact problematic path. So while we have no public proof of weaponized exploitation, the bug is real and demonstrable.

How We Got Here

GFS2 has always walked a tightrope between performance and safety. To manage clustered metadata, it runs transactions that must not be interrupted by other filesystem code—especially not by memory reclaim, which can fire at any time.

The vulnerable code was in the inode creation path, which set the mapping’s gfp_mask to GFP_HIGHUSER_MOVABLE. That flag inherited __GFP_FS from its definition, allowing the allocator to call back into filesystem code if needed. When memory pressure hit, that callback could start a new transaction before the current one finished, leading to a deadlock.

This pattern isn’t new. XFS had to harden itself against the same class of bug years ago, and the kernel’s memory management guidelines have long warned against using __GFP_FS inside transaction contexts. The GFS2 case was simply an oversight that slipped through until fuzzers and test suites caught it.

The fix landed in upstream stable kernels on December 24, 2025, with the NVD publishing shortly after. Distribution trackers like OSV and SUSE’s CVE database have imported the advisory, so package-level fixes are rolling out now.

What You Need to Do Right Now

Step 1: Confirm you’re exposed. Run these commands:

grep -i gfs2 /boot/config-$(uname -r) 2>/dev/null || zcat /proc/config.gz | grep -i gfs2
lsmod | grep gfs2
grep gfs2 /proc/mounts

If any of those return output, you have GFS2 support loaded or a filesystem mounted. Prioritize these systems.

Step 2: Find your vendor’s patch. Check your distribution’s security tracker for CVE-2025-68356. On Debian/Ubuntu, apt changelog linux-image-$(uname -r) may show the fix; on RHEL/SUSE, rpm -q --changelog kernel and the vendor advisory page are your friends. Match the upstream commit IDs from the NVD entry to your package’s changelog.

Step 3: Update and reboot. Kernel memory flag changes demand a reboot—livepatching isn’t guaranteed to cover this. Schedule maintenance immediately for cluster nodes and shared-storage hosts. For bare-metal clusters, consider rolling reboots with proper fencing to avoid split-brain.

Step 4: If you can’t patch now, harden.
- Restrict who can mount or write to shared block devices.
- Avoid metadata-heavy workloads (mass creates, deletes, renames) that stress transaction paths.
- Isolate untrusted tenants or test workloads to separate nodes.

Step 5: Verify. After rebooting, confirm uname -r matches your patched kernel, and watch dmesg for any lingering GFS2 oops or hangs. If you experienced a crash before patching, capture a vmcore before rebooting—forensic traces are gold for vendor escalation.

The Fix Is Good Engineering—But Stay Vigilant

The patch is a masterclass in minimal surgery. It removes one flag from one code path, avoiding a cascade of side effects. The kernel team deliberately chose not to switch to GFP_NOFS globally; instead, they kept the default mask and only cleared the __GFP_FS bit, preserving allocation flexibility where it’s safe.

That said, this is a single-point fix. Other filesystems or kernel subsystems might have similar __GFP_FS leaks in transaction-sensitive paths. Watch for follow-up advisories, and keep your test environments stocked with xfstest runs to catch regressions early.

Distribution backport quality matters. A sloppy backport could inadvertently set an overly restrictive mask, causing allocation failures. When updating, cross-check your kernel’s patch list against the upstream commit hash to ensure the fix was applied verbatim.

Finally, don’t hang your risk assessment on a CVSS score. The NVD entry doesn’t publish one yet, but that doesn’t diminish the danger. If your production cluster runs GFS2, a deadlock is a Sev-1 incident waiting to happen.

What to Watch Next

Kernel maintainers will likely audit other filesystems for similar __GFP_FS uses inside transaction code. Watch the linux-fsdevel and cluster-devel mailing lists for patches. If you run a non-GFS2 clustered filesystem (OCFS2, for instance), keep an eye on your vendor’s advisory page—the principles are transferable.

For now, the message is simple: if GFS2 is in your stack, patch by your next maintenance window. The fix is small, the risk is real, and the only thing standing between you and a 3 a.m. kernel panic is a single flag flip.