gfs2: Prevent recursive memory reclaim
Summary
| CVE | CVE-2025-68356 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2025-12-24 11:15:58 UTC |
| Updated | 2026-10-21 13:18:22 UTC |
| Description | In the Linux kernel, the following vulnerability has been resolved:
gfs2: Prevent recursive memory reclaim
Function new_inode() returns a new inode with inode->i_mapping->gfp_mask
set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so
allocations in that address space can recurse into filesystem memory
reclaim. We don't want that to happen because it can consume a
significant amount of stack memory.
Worse than that is that it can also deadlock: for example, in several
places, gfs2_unstuff_dinode() is called inside filesystem transactions.
This calls filemap_grab_folio(), which can allocate a new folio, which
can trigger memory reclaim. If memory reclaim recurses into the
filesystem and starts another transaction, a deadlock will ensue.
To fix these kinds of problems, prevent memory reclaim from recursing
into filesystem code by making sure that the gfp_mask of inode address
spaces doesn't include __GFP_FS.
The "meta" and resource group address spaces were already using GFP_NOFS
as their gfp_mask (which doesn't include __GFP_FS). The default value
of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To
avoid being overly limiting, use the default value and only knock off
the __GFP_FS flag. I'm not sure if this will actually make a
difference, but it also shouldn't hurt.
This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack
overflows from page cache allocation").
Fixes xfstest generic/273. |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected dc0b9435238c1a68150c798c9c7a1b5d7414cbb9 66eb53cecc5f83183535bbfb2fa6464322049b61 git |
Not specified |
| CNA |
Linux |
Linux |
affected dc0b9435238c1a68150c798c9c7a1b5d7414cbb9 edb2b255618621dc83d0ec23150e16b2c697077f git |
Not specified |
| CNA |
Linux |
Linux |
affected dc0b9435238c1a68150c798c9c7a1b5d7414cbb9 9c0960ed112398bdb6c60ccf6e6b583bc59acede git |
Not specified |
| CNA |
Linux |
Linux |
affected dc0b9435238c1a68150c798c9c7a1b5d7414cbb9 49e7347f4644d031306d56cb4d51e467cbdcbc69 git |
Not specified |
| CNA |
Linux |
Linux |
affected dc0b9435238c1a68150c798c9c7a1b5d7414cbb9 2c5f4a53476e3cab70adc77b38942c066bd2c17c git |
Not specified |
| CNA |
Linux |
Linux |
affected 6.6 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.6 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.6.160 6.6.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.63 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.17.13 6.17.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.2 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.19 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/9c0960ed112398bdb6c60ccf6e6b583bc59acede |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/66eb53cecc5f83183535bbfb2fa6464322049b61 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/2c5f4a53476e3cab70adc77b38942c066bd2c17c |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/edb2b255618621dc83d0ec23150e16b2c697077f |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/49e7347f4644d031306d56cb4d51e467cbdcbc69 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.