{"api_version":"1","generated_at":"2026-04-23T04:11:06+00:00","cve":"CVE-2026-31448","urls":{"html":"https://cve.report/CVE-2026-31448","api":"https://cve.report/api/cve/CVE-2026-31448.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-31448","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-31448"},"summary":{"title":"ext4: avoid infinite loops caused by residual data","description":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid infinite loops caused by residual data\n\nOn the mkdir/mknod path, when mapping logical blocks to physical blocks,\nif inserting a new extent into the extent tree fails (in this example,\nbecause the file system disabled the huge file feature when marking the\ninode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to\nreclaim the physical block without deleting the corresponding data in\nthe extent tree. This causes subsequent mkdir operations to reference\nthe previously reclaimed physical block number again, even though this\nphysical block is already being used by the xattr block. Therefore, a\nsituation arises where both the directory and xattr are using the same\nbuffer head block in memory simultaneously.\n\nThe above causes ext4_xattr_block_set() to enter an infinite loop about\n\"inserted\" and cannot release the inode lock, ultimately leading to the\n143s blocking problem mentioned in [1].\n\nIf the metadata is corrupted, then trying to remove some extent space\ncan do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE\nwas passed, remove space wrongly update quota information.\nJan Kara suggests distinguishing between two cases:\n\n1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully\nconsistent and we must maintain its consistency including all the\naccounting. However these errors can happen only early before we've\ninserted the extent into the extent tree. So current code works correctly\nfor this case.\n\n2) Some other error - this means metadata is corrupted. We should strive to\ndo as few modifications as possible to limit damage. So I'd just skip\nfreeing of allocated blocks.\n\n[1]\nINFO: task syz.0.17:5995 blocked for more than 143 seconds.\nCall Trace:\n inode_lock_nested include/linux/fs.h:1073 [inline]\n __start_dirop fs/namei.c:2923 [inline]\n start_dirop fs/namei.c:2934 [inline]","state":"PUBLISHED","assigner":"Linux","published_at":"2026-04-22 14:16:38","updated_at":"2026-04-22 14:16:38"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5","name":"https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9","name":"https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c","name":"https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c","name":"https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412","name":"https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b","name":"https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-31448","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31448","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 c66545e83a802c3851d9be27a41c0479dd29ff0c git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ecc50bfca9b5c2ee6aeef998181689b80477367b git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 3a7667595bcad84da53fc156a418e110267c3412 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 416c86f30f91b4fb2642ef6b102596ca898f41a5 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 64f425b06b3bea9abc8977fd3982779b3ad070c9 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 5422fe71d26d42af6c454ca9527faaad4e677d6c git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1.168 6.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.131 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.80 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.21 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19.11 6.19.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/ext4/extents.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"c66545e83a802c3851d9be27a41c0479dd29ff0c","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"ecc50bfca9b5c2ee6aeef998181689b80477367b","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"3a7667595bcad84da53fc156a418e110267c3412","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"416c86f30f91b4fb2642ef6b102596ca898f41a5","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"64f425b06b3bea9abc8977fd3982779b3ad070c9","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"5422fe71d26d42af6c454ca9527faaad4e677d6c","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/ext4/extents.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThanOrEqual":"6.1.*","status":"unaffected","version":"6.1.168","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.131","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.80","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.21","versionType":"semver"},{"lessThanOrEqual":"6.19.*","status":"unaffected","version":"6.19.11","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.0","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.1.168","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.131","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.80","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.21","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.19.11","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.0","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid infinite loops caused by residual data\n\nOn the mkdir/mknod path, when mapping logical blocks to physical blocks,\nif inserting a new extent into the extent tree fails (in this example,\nbecause the file system disabled the huge file feature when marking the\ninode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to\nreclaim the physical block without deleting the corresponding data in\nthe extent tree. This causes subsequent mkdir operations to reference\nthe previously reclaimed physical block number again, even though this\nphysical block is already being used by the xattr block. Therefore, a\nsituation arises where both the directory and xattr are using the same\nbuffer head block in memory simultaneously.\n\nThe above causes ext4_xattr_block_set() to enter an infinite loop about\n\"inserted\" and cannot release the inode lock, ultimately leading to the\n143s blocking problem mentioned in [1].\n\nIf the metadata is corrupted, then trying to remove some extent space\ncan do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE\nwas passed, remove space wrongly update quota information.\nJan Kara suggests distinguishing between two cases:\n\n1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully\nconsistent and we must maintain its consistency including all the\naccounting. However these errors can happen only early before we've\ninserted the extent into the extent tree. So current code works correctly\nfor this case.\n\n2) Some other error - this means metadata is corrupted. We should strive to\ndo as few modifications as possible to limit damage. So I'd just skip\nfreeing of allocated blocks.\n\n[1]\nINFO: task syz.0.17:5995 blocked for more than 143 seconds.\nCall Trace:\n inode_lock_nested include/linux/fs.h:1073 [inline]\n __start_dirop fs/namei.c:2923 [inline]\n start_dirop fs/namei.c:2934 [inline]"}],"providerMetadata":{"dateUpdated":"2026-04-22T13:53:44.129Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c"},{"url":"https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b"},{"url":"https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412"},{"url":"https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5"},{"url":"https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9"},{"url":"https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c"}],"title":"ext4: avoid infinite loops caused by residual data","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-31448","datePublished":"2026-04-22T13:53:44.129Z","dateReserved":"2026-03-09T15:48:24.091Z","dateUpdated":"2026-04-22T13:53:44.129Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-04-22 14:16:38","lastModifiedDate":"2026-04-22 14:16:38","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"31448","Ordinal":"1","Title":"ext4: avoid infinite loops caused by residual data","CVE":"CVE-2026-31448","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"31448","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid infinite loops caused by residual data\n\nOn the mkdir/mknod path, when mapping logical blocks to physical blocks,\nif inserting a new extent into the extent tree fails (in this example,\nbecause the file system disabled the huge file feature when marking the\ninode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to\nreclaim the physical block without deleting the corresponding data in\nthe extent tree. This causes subsequent mkdir operations to reference\nthe previously reclaimed physical block number again, even though this\nphysical block is already being used by the xattr block. Therefore, a\nsituation arises where both the directory and xattr are using the same\nbuffer head block in memory simultaneously.\n\nThe above causes ext4_xattr_block_set() to enter an infinite loop about\n\"inserted\" and cannot release the inode lock, ultimately leading to the\n143s blocking problem mentioned in [1].\n\nIf the metadata is corrupted, then trying to remove some extent space\ncan do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE\nwas passed, remove space wrongly update quota information.\nJan Kara suggests distinguishing between two cases:\n\n1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully\nconsistent and we must maintain its consistency including all the\naccounting. However these errors can happen only early before we've\ninserted the extent into the extent tree. So current code works correctly\nfor this case.\n\n2) Some other error - this means metadata is corrupted. We should strive to\ndo as few modifications as possible to limit damage. So I'd just skip\nfreeing of allocated blocks.\n\n[1]\nINFO: task syz.0.17:5995 blocked for more than 143 seconds.\nCall Trace:\n inode_lock_nested include/linux/fs.h:1073 [inline]\n __start_dirop fs/namei.c:2923 [inline]\n start_dirop fs/namei.c:2934 [inline]","Type":"Description","Title":"ext4: avoid infinite loops caused by residual data"}]}}}