CVE-2025-71069
Status: DeferredUnscored—
In the Linux kernel, the following vulnerability has been resolved:
f2fs: invalidate dentry cache on failed whiteout creation
F2FS can mount filesystems with corrupted directory depth values that get runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUT operations are performed on such directories, f2fs_rename performs directory modifications (updating target entry and deleting source entry) before attempting to add the whiteout entry via f2fs_add_link.
If f2fs_add_link fails due to the corrupted directory structure, the function returns an error to VFS, but the partial directory modifications have already been committed to disk. VFS assumes the entire rename operation failed and does not update the dentry cache, leaving stale mappings.
Read full descriptionShow less
In the error path, VFS does not call d_move() to update the dentry cache. This results in new_dentry still pointing to the old inode (new_inode) which has already had its i_nlink decremented to zero. The stale cache causes subsequent operations to incorrectly reference the freed inode.
This causes subsequent operations to use cached dentry information that no longer matches the on-disk state. When a second rename targets the same entry, VFS attempts to decrement i_nlink on the stale inode, which may already have i_nlink=0, triggering a WARNING in drop_nlink().
Fix this by explicitly invalidating old_dentry and new_dentry when f2fs_add_link fails during whiteout creation. This forces VFS to refresh from disk on subsequent operations, ensuring cache consistency even when the rename partially succeeds.
Reproducer: 1. Mount F2FS image with corrupted i_current_depth 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. System triggers WARNING in drop_nlink()
Technical details traces, logs and code from the original report
Example sequence: 1. First rename (RENAME_WHITEOUT): file2 → file1 - f2fs updates file1 entry on disk (points to inode 8) - f2fs deletes file2 entry on disk - f2fs_add_link(whiteout) fails (corrupted directory) - Returns error to VFS - VFS does not call d_move() due to error - VFS cache still has: file1 → inode 7 (stale!) - inode 7 has i_nlink=0 (already decremented) 2. Second rename: file3 → file1 - VFS uses stale cache: file1 → inode 7 - Tries to drop_nlink on inode 7 (i_nlink already 0) - WARNING in drop_nlink()
CVSS
NVD hasn't assigned a CVSS score to this CVE (common since the April 2026 policy change).
Exploitation probability (EPSS)
- Probability of exploitation in the next 30 days: 0.20%
- Percentile among all scored CVEs: 9
- Score date: 10/4/2026
EPSS (Exploit Prediction Scoring System, FIRST) estimates how likely a vulnerability is to be exploited in the wild within 30 days. It complements CVSS (impact) and CISA KEV (confirmed exploitation).
Affected technologies (1)
⚠ AI-inferred from the description — NVD hasn't analyzed this CVE yet, these aren't verified CPEs.
References
- https://git.kernel.org/stable/c/0dde30753c1e8648665dbe069d814e540ce2fd37
- https://git.kernel.org/stable/c/3d65e27e57aaa9d66709fda4cbfb62a87c04a3f5
- https://git.kernel.org/stable/c/3d95ed8cf980fdfa67a3ab9491357521ae576168
- https://git.kernel.org/stable/c/64587ab4d1f16fc94f70e04fa87b2e3f69f8a7bb
- https://git.kernel.org/stable/c/7f2bae0c881aa1e0a6318756df692cc13df2cc83
- https://git.kernel.org/stable/c/c89845fae250efdd59c1d4ec60e9e1c652cee4b6
- https://git.kernel.org/stable/c/d33f89b34aa313f50f9a512d58dd288999f246b0
Raw JSON (NVD)
Show
{
"id": "CVE-2025-71069",
"cveTags": [],
"metrics": {},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "7e01e7ad746bc8198a8b46163ddc73a1c7d22339",
"lessThan": "7f2bae0c881aa1e0a6318756df692cc13df2cc83",
"versionType": "git"
},
{
"status": "affected",
"version": "7e01e7ad746bc8198a8b46163ddc73a1c7d22339",
"lessThan": "3d95ed8cf980fdfa67a3ab9491357521ae576168",
"versionType": "git"
},
{
"status": "affected",
"version": "7e01e7ad746bc8198a8b46163ddc73a1c7d22339",
"lessThan": "64587ab4d1f16fc94f70e04fa87b2e3f69f8a7bb",
"versionType": "git"
},
{
"status": "affected",
"version": "7e01e7ad746bc8198a8b46163ddc73a1c7d22339",
"lessThan": "3d65e27e57aaa9d66709fda4cbfb62a87c04a3f5",
"versionType": "git"
},
{
"status": "affected",
"version": "7e01e7ad746bc8198a8b46163ddc73a1c7d22339",
"lessThan": "c89845fae250efdd59c1d4ec60e9e1c652cee4b6",
"versionType": "git"
},
{
"status": "affected",
"version": "7e01e7ad746bc8198a8b46163ddc73a1c7d22339",
"lessThan": "0dde30753c1e8648665dbe069d814e540ce2fd37",
"versionType": "git"
},
{
"status": "affected",
"version": "7e01e7ad746bc8198a8b46163ddc73a1c7d22339",
"lessThan": "d33f89b34aa313f50f9a512d58dd288999f246b0",
"versionType": "git"
}
],
"programFiles": [
"fs/f2fs/namei.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "4.2"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "4.2",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "5.10.248",
"versionType": "semver",
"lessThanOrEqual": "5.10.*"
},
{
"status": "unaffected",
"version": "5.15.198",
"versionType": "semver",
"lessThanOrEqual": "5.15.*"
},
{
"status": "unaffected",
"version": "6.1.160",
"versionType": "semver",
"lessThanOrEqual": "6.1.*"
},
{
"status": "unaffected",
"version": "6.6.120",
"versionType": "semver",
"lessThanOrEqual": "6.6.*"
},
{
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver",
"lessThanOrEqual": "6.12.*"
},
{
"status": "unaffected",
"version": "6.18.3",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"fs/f2fs/namei.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-01-13T16:16:06.300",
"references": [
{
"url": "https://git.kernel.org/stable/c/0dde30753c1e8648665dbe069d814e540ce2fd37",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/3d65e27e57aaa9d66709fda4cbfb62a87c04a3f5",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/3d95ed8cf980fdfa67a3ab9491357521ae576168",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/64587ab4d1f16fc94f70e04fa87b2e3f69f8a7bb",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/7f2bae0c881aa1e0a6318756df692cc13df2cc83",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/c89845fae250efdd59c1d4ec60e9e1c652cee4b6",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/d33f89b34aa313f50f9a512d58dd288999f246b0",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Deferred",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: invalidate dentry cache on failed whiteout creation\n\nF2FS can mount filesystems with corrupted directory depth values that\nget runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUT\noperations are performed on such directories, f2fs_rename performs\ndirectory modifications (updating target entry and deleting source\nentry) before attempting to add the whiteout entry via f2fs_add_link.\n\nIf f2fs_add_link fails due to the corrupted directory structure, the\nfunction returns an error to VFS, but the partial directory\nmodifications have already been committed to disk. VFS assumes the\nentire rename operation failed and does not update the dentry cache,\nleaving stale mappings.\n\nIn the error path, VFS does not call d_move() to update the dentry\ncache. This results in new_dentry still pointing to the old inode\n(new_inode) which has already had its i_nlink decremented to zero.\nThe stale cache causes subsequent operations to incorrectly reference\nthe freed inode.\n\nThis causes subsequent operations to use cached dentry information that\nno longer matches the on-disk state. When a second rename targets the\nsame entry, VFS attempts to decrement i_nlink on the stale inode, which\nmay already have i_nlink=0, triggering a WARNING in drop_nlink().\n\nExample sequence:\n1. First rename (RENAME_WHITEOUT): file2 → file1\n - f2fs updates file1 entry on disk (points to inode 8)\n - f2fs deletes file2 entry on disk\n - f2fs_add_link(whiteout) fails (corrupted directory)\n - Returns error to VFS\n - VFS does not call d_move() due to error\n - VFS cache still has: file1 → inode 7 (stale!)\n - inode 7 has i_nlink=0 (already decremented)\n\n2. Second rename: file3 → file1\n - VFS uses stale cache: file1 → inode 7\n - Tries to drop_nlink on inode 7 (i_nlink already 0)\n - WARNING in drop_nlink()\n\nFix this by explicitly invalidating old_dentry and new_dentry when\nf2fs_add_link fails during whiteout creation. This forces VFS to\nrefresh from disk on subsequent operations, ensuring cache consistency\neven when the rename partially succeeds.\n\nReproducer:\n1. Mount F2FS image with corrupted i_current_depth\n2. renameat2(file2, file1, RENAME_WHITEOUT)\n3. renameat2(file3, file1, 0)\n4. System triggers WARNING in drop_nlink()"
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nf2fs: invalidar la caché de dentry en la creación fallida de whiteout\n\nF2FS puede montar sistemas de archivos con valores de profundidad de directorio corruptos que se ajustan en tiempo de ejecución a MAX_DIR_HASH_DEPTH. Cuando se realizan operaciones RENAME_WHITEOUT en dichos directorios, f2fs_rename realiza modificaciones de directorio (actualizando la entrada de destino y eliminando la entrada de origen) antes de intentar añadir la entrada de whiteout a través de f2fs_add_link.\n\nSi f2fs_add_link falla debido a la estructura de directorio corrupta, la función devuelve un error a VFS, pero las modificaciones parciales del directorio ya se han confirmado en el disco. VFS asume que toda la operación de renombrado falló y no actualiza la caché de dentry, dejando mapeos obsoletos.\n\nEn la ruta de error, VFS no llama a d_move() para actualizar la caché de dentry. Esto resulta en que new_dentry sigue apuntando al antiguo inodo (new_inode) al que ya se le ha decrementado su i_nlink a cero. La caché obsoleta causa que las operaciones subsiguientes referencien incorrectamente el inodo liberado.\n\nEsto hace que las operaciones subsiguientes utilicen información de dentry en caché que ya no coincide con el estado en disco. Cuando un segundo renombrado apunta a la misma entrada, VFS intenta decrementar i_nlink en el inodo obsoleto, que ya puede tener i_nlink=0, lo que activa una ADVERTENCIA en drop_nlink().\n\nSecuencia de ejemplo:\n1. Primer renombrado (RENAME_WHITEOUT): file2 ? file1\n - f2fs actualiza la entrada file1 en disco (apunta al inodo 8)\n - f2fs elimina la entrada file2 en disco\n - f2fs_add_link(whiteout) falla (directorio corrupto)\n - Devuelve error a VFS\n - VFS no llama a d_move() debido al error\n - La caché de VFS todavía tiene: file1 ? inodo 7 (¡obsoleto!)\n - el inodo 7 tiene i_nlink=0 (ya decrementado)\n\n2. Segundo renombrado: file3 ? file1\n - VFS usa caché obsoleta: file1 ? inodo 7\n - Intenta drop_nlink en el inodo 7 (i_nlink ya es 0)\n - ADVERTENCIA en drop_nlink()\n\nSolucione esto invalidando explícitamente old_dentry y new_dentry cuando f2fs_add_link falla durante la creación de whiteout. Esto fuerza a VFS a actualizarse desde el disco en operaciones subsiguientes, asegurando la consistencia de la caché incluso cuando el renombrado tiene éxito parcialmente.\n\nReproductor:\n1. Monte la imagen F2FS con i_current_depth corrupto\n2. renameat2(file2, file1, RENAME_WHITEOUT)\n3. renameat2(file3, file1, 0)\n4. El sistema activa una ADVERTENCIA en drop_nlink()"
}
],
"lastModified": "2026-06-17T10:03:35.880",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}