FKIE_CVE-2025-68356
Vulnerability from fkie_nvd - Published: 2025-12-24 11:15 - Updated: 2026-10-21 13:18
Severity
Summary
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/gfs2/glock.c",
"fs/gfs2/inode.c",
"fs/gfs2/inode.h",
"fs/gfs2/ops_fstype.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "66eb53cecc5f83183535bbfb2fa6464322049b61",
"status": "affected",
"version": "dc0b9435238c1a68150c798c9c7a1b5d7414cbb9",
"versionType": "git"
},
{
"lessThan": "edb2b255618621dc83d0ec23150e16b2c697077f",
"status": "affected",
"version": "dc0b9435238c1a68150c798c9c7a1b5d7414cbb9",
"versionType": "git"
},
{
"lessThan": "9c0960ed112398bdb6c60ccf6e6b583bc59acede",
"status": "affected",
"version": "dc0b9435238c1a68150c798c9c7a1b5d7414cbb9",
"versionType": "git"
},
{
"lessThan": "49e7347f4644d031306d56cb4d51e467cbdcbc69",
"status": "affected",
"version": "dc0b9435238c1a68150c798c9c7a1b5d7414cbb9",
"versionType": "git"
},
{
"lessThan": "2c5f4a53476e3cab70adc77b38942c066bd2c17c",
"status": "affected",
"version": "dc0b9435238c1a68150c798c9c7a1b5d7414cbb9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/gfs2/glock.c",
"fs/gfs2/inode.c",
"fs/gfs2/inode.h",
"fs/gfs2/ops_fstype.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.6"
},
{
"lessThan": "6.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.160",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.63",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Prevent recursive memory reclaim\n\nFunction new_inode() returns a new inode with inode-\u003ei_mapping-\u003egfp_mask\nset to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so\nallocations in that address space can recurse into filesystem memory\nreclaim. We don\u0027t want that to happen because it can consume a\nsignificant amount of stack memory.\n\nWorse than that is that it can also deadlock: for example, in several\nplaces, gfs2_unstuff_dinode() is called inside filesystem transactions.\nThis calls filemap_grab_folio(), which can allocate a new folio, which\ncan trigger memory reclaim. If memory reclaim recurses into the\nfilesystem and starts another transaction, a deadlock will ensue.\n\nTo fix these kinds of problems, prevent memory reclaim from recursing\ninto filesystem code by making sure that the gfp_mask of inode address\nspaces doesn\u0027t include __GFP_FS.\n\nThe \"meta\" and resource group address spaces were already using GFP_NOFS\nas their gfp_mask (which doesn\u0027t include __GFP_FS). The default value\nof GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To\navoid being overly limiting, use the default value and only knock off\nthe __GFP_FS flag. I\u0027m not sure if this will actually make a\ndifference, but it also shouldn\u0027t hurt.\n\nThis patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack\noverflows from page cache allocation\").\n\nFixes xfstest generic/273."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\ngfs2: Prevenir la recuperaci\u00f3n de memoria recursiva\n\nLa funci\u00f3n new_inode() devuelve un nuevo inodo con inode -\u003e i_mapping -\u003e gfp_mask establecido en GFP_HIGHUSER_MOVABLE. Este valor incluye la bandera __GFP_FS, por lo que las asignaciones en ese espacio de direcciones pueden recursar en la recuperaci\u00f3n de memoria del sistema de archivos. No queremos que eso suceda porque puede consumir una cantidad significativa de memoria de pila.\n\nPeor a\u00fan es que tambi\u00e9n puede provocar un interbloqueo: por ejemplo, en varios lugares, se llama a gfs2_unstuff_dinode() dentro de transacciones del sistema de archivos. Esto llama a filemap_grab_folio(), que puede asignar un nuevo folio, lo que puede desencadenar la recuperaci\u00f3n de memoria. Si la recuperaci\u00f3n de memoria recursa en el sistema de archivos y comienza otra transacci\u00f3n, se producir\u00e1 un interbloqueo.\n\nPara solucionar este tipo de problemas, se evita que la recuperaci\u00f3n de memoria recurse en el c\u00f3digo del sistema de archivos asegur\u00e1ndose de que el gfp_mask de los espacios de direcciones de inodos no incluya __GFP_FS.\n\nLos espacios de direcciones de \u0027meta\u0027 y de grupo de recursos ya estaban usando GFP_NOFS como su gfp_mask (que no incluye __GFP_FS). El valor predeterminado de GFP_HIGHUSER_MOVABLE es menos restrictivo que GFP_NOFS, sin embargo. Para evitar ser excesivamente restrictivo, se usa el valor predeterminado y solo se elimina la bandera __GFP_FS. No estoy seguro de si esto realmente marcar\u00e1 una diferencia, pero tampoco deber\u00eda perjudicar.\n\nEste parche se basa libremente en el commit ad22c7a043c2 (\u0027xfs: prevenir desbordamientos de pila por asignaci\u00f3n de cach\u00e9 de p\u00e1gina\u0027).\n\nSoluciona xfstest generic/273."
}
],
"id": "CVE-2025-68356",
"lastModified": "2026-10-21T13:18:22.723",
"metrics": {},
"published": "2025-12-24T11:15:58.967",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2c5f4a53476e3cab70adc77b38942c066bd2c17c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/49e7347f4644d031306d56cb4d51e467cbdcbc69"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/66eb53cecc5f83183535bbfb2fa6464322049b61"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9c0960ed112398bdb6c60ccf6e6b583bc59acede"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/edb2b255618621dc83d0ec23150e16b2c697077f"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.