Vulnerability-Lookup

CVE-2026-31448 (GCVE-0-2026-31448)

Vulnerability from cvelistv5 – Published: 2026-04-22 13:53 – Updated: 2026-04-23 15:18

Title

ext4: avoid infinite loops caused by residual data

Summary

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid infinite loops caused by residual data On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously. The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1]. If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases: 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case. 2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks. [1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]

Severity ?

No CVSS data available.

Assigner

Linux

References

URL

Tags

	https://git.kernel.org/stable/c/c66545e83a802c385…
	https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6…
	https://git.kernel.org/stable/c/3a7667595bcad84da…
	https://git.kernel.org/stable/c/416c86f30f91b4fb2…
	https://git.kernel.org/stable/c/64f425b06b3bea9ab…
	https://git.kernel.org/stable/c/5422fe71d26d42af6…

Impacted products

Vendor

Product

Version

Linux

Affected: 315054f023d28ee64f308adf8b5737831541776b , < c66545e83a802c3851d9be27a41c0479dd29ff0c (git)
Affected: 315054f023d28ee64f308adf8b5737831541776b , < ecc50bfca9b5c2ee6aeef998181689b80477367b (git)
Affected: 315054f023d28ee64f308adf8b5737831541776b , < 3a7667595bcad84da53fc156a418e110267c3412 (git)
Affected: 315054f023d28ee64f308adf8b5737831541776b , < 416c86f30f91b4fb2642ef6b102596ca898f41a5 (git)
Affected: 315054f023d28ee64f308adf8b5737831541776b , < 64f425b06b3bea9abc8977fd3982779b3ad070c9 (git)
Affected: 315054f023d28ee64f308adf8b5737831541776b , < 5422fe71d26d42af6c454ca9527faaad4e677d6c (git)

Linux

Affected: 2.6.22
Unaffected: 0 , < 2.6.22 (semver)
Unaffected: 6.1.168 , ≤ 6.1.* (semver)
Unaffected: 6.6.131 , ≤ 6.6.* (semver)
Unaffected: 6.12.80 , ≤ 6.12.* (semver)
Unaffected: 6.18.21 , ≤ 6.18.* (semver)
Unaffected: 6.19.11 , ≤ 6.19.* (semver)
Unaffected: 7.0 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "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": "315054f023d28ee64f308adf8b5737831541776b",
              "versionType": "git"
            },
            {
              "lessThan": "ecc50bfca9b5c2ee6aeef998181689b80477367b",
              "status": "affected",
              "version": "315054f023d28ee64f308adf8b5737831541776b",
              "versionType": "git"
            },
            {
              "lessThan": "3a7667595bcad84da53fc156a418e110267c3412",
              "status": "affected",
              "version": "315054f023d28ee64f308adf8b5737831541776b",
              "versionType": "git"
            },
            {
              "lessThan": "416c86f30f91b4fb2642ef6b102596ca898f41a5",
              "status": "affected",
              "version": "315054f023d28ee64f308adf8b5737831541776b",
              "versionType": "git"
            },
            {
              "lessThan": "64f425b06b3bea9abc8977fd3982779b3ad070c9",
              "status": "affected",
              "version": "315054f023d28ee64f308adf8b5737831541776b",
              "versionType": "git"
            },
            {
              "lessThan": "5422fe71d26d42af6c454ca9527faaad4e677d6c",
              "status": "affected",
              "version": "315054f023d28ee64f308adf8b5737831541776b",
              "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": [
            {
              "status": "affected",
              "version": "2.6.22"
            },
            {
              "lessThan": "2.6.22",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "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",
                  "versionStartIncluding": "2.6.22",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.131",
                  "versionStartIncluding": "2.6.22",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.80",
                  "versionStartIncluding": "2.6.22",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.21",
                  "versionStartIncluding": "2.6.22",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.19.11",
                  "versionStartIncluding": "2.6.22",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0",
                  "versionStartIncluding": "2.6.22",
                  "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\u0027ve\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\u0027d 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-23T15:18:26.123Z",
        "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-23T15:18:26.123Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-31448",
      "date": "2026-04-23",
      "epss": "0.00024",
      "percentile": "0.06794"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-31448\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-04-22T14:16:38.760\",\"lastModified\":\"2026-04-23T16:17:41.280\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"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\u0027ve\\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\u0027d 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]\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}

FKIE_CVE-2026-31448

Vulnerability from fkie_nvd - Published: 2026-04-22 14:16 - Updated: 2026-04-23 16:17

Severity ?

Summary

References

	URL	Tags
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "cveTags": [],
  "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\u0027ve\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\u0027d 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]"
    }
  ],
  "id": "CVE-2026-31448",
  "lastModified": "2026-04-23T16:17:41.280",
  "metrics": {},
  "published": "2026-04-22T14:16:38.760",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}

GHSA-M6JJ-C3PV-CG65

Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-22 15:31

Details

In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid infinite loops caused by residual data

On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously.

The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1].

If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases:

1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case.

2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks.

[1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-31448"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-22T14:16:38Z",
    "severity": null
  },
  "details": "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\u0027ve\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\u0027d 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]",
  "id": "GHSA-m6jj-c3pv-cg65",
  "modified": "2026-04-22T15:31:41Z",
  "published": "2026-04-22T15:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31448"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

MSRC_CVE-2026-31448

Vulnerability from csaf_microsoft - Published: 2026-04-02 00:00 - Updated: 2026-04-24 01:37

Summary

ext4: avoid infinite loops caused by residual data

Notes

Additional Resources: To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

Disclaimer: The information provided in the Microsoft Knowledge Base is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

CVE-2026-31448

None Available There is no fix available for this vulnerability as of now

References

URL

Sightings

Author	Source	Type	Date

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.

Detection rules are retrieved from Rulezet.

Action not permitted

CVE-2026-31448 (GCVE-0-2026-31448)

FKIE_CVE-2026-31448

GHSA-M6JJ-C3PV-CG65

MSRC_CVE-2026-31448

Tags

Sightings

Nomenclature