fkie_cve-2024-26726
Vulnerability from fkie_nvd
Published
2024-04-03 15:15
Modified
2025-07-10 15:15
Severity ?
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map. Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/143842584c1237ebc248b2547c29d16bbe400a92
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0adePatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535ePatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0adePatch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7Patch
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535ePatch
Impacted products
Vendor Product Version
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel 6.8
linux linux_kernel 6.8
linux linux_kernel 6.8
linux linux_kernel 6.8


To clipboard 

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "0CD66F01-9687-41BC-ADEE-C4E51121167A",
              "versionEndExcluding": "6.1.79",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "BD961E49-FEDA-47CF-BF23-4D2BD942B4E0",
              "versionEndExcluding": "6.6.18",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "C6D6A5C8-7308-42A9-8A72-ABF3DEA4BB82",
              "versionEndExcluding": "6.7.6",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:*",
              "matchCriteriaId": "B9F4EA73-0894-400F-A490-3A397AB7A517",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*",
              "matchCriteriaId": "056BD938-0A27-4569-B391-30578B309EE3",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*",
              "matchCriteriaId": "F02056A5-B362-4370-9FF8-6F0BD384D520",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*",
              "matchCriteriaId": "62075ACE-B2A0-4B16-829D-B3DA5AE5CC41",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don\u0027t drop extent_map for free space inode on write error\n\nWhile running the CI for an unrelated change I hit the following panic\nwith generic/648 on btrfs_holes_spacecache.\n\nassertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385\n------------[ cut here ]------------\nkernel BUG at fs/btrfs/extent_io.c:1385!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1\nRIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0\nCall Trace:\n \u003cTASK\u003e\n extent_write_cache_pages+0x2ac/0x8f0\n extent_writepages+0x87/0x110\n do_writepages+0xd5/0x1f0\n filemap_fdatawrite_wbc+0x63/0x90\n __filemap_fdatawrite_range+0x5c/0x80\n btrfs_fdatawrite_range+0x1f/0x50\n btrfs_write_out_cache+0x507/0x560\n btrfs_write_dirty_block_groups+0x32a/0x420\n commit_cowonly_roots+0x21b/0x290\n btrfs_commit_transaction+0x813/0x1360\n btrfs_sync_file+0x51a/0x640\n __x64_sys_fdatasync+0x52/0x90\n do_syscall_64+0x9c/0x190\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nThis happens because we fail to write out the free space cache in one\ninstance, come back around and attempt to write it again.  However on\nthe second pass through we go to call btrfs_get_extent() on the inode to\nget the extent mapping.  Because this is a new block group, and with the\nfree space inode we always search the commit root to avoid deadlocking\nwith the tree, we find nothing and return a EXTENT_MAP_HOLE for the\nrequested range.\n\nThis happens because the first time we try to write the space cache out\nwe hit an error, and on an error we drop the extent mapping.  This is\nnormal for normal files, but the free space cache inode is special.  We\nalways expect the extent map to be correct.  Thus the second time\nthrough we end up with a bogus extent map.\n\nSince we\u0027re deprecating this feature, the most straightforward way to\nfix this is to simply skip dropping the extent map range for this failed\nrange.\n\nI shortened the test by using error injection to stress the area to make\nit easier to reproduce.  With this patch in place we no longer panic\nwith my error injection test."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: btrfs: no elimine extend_map para el inodo de espacio libre en el error de escritura Mientras ejecutaba el CI para un cambio no relacionado, encontr\u00e9 el siguiente p\u00e1nico con generic/648 en btrfs_holes_spacecache. error de aserci\u00f3n: block_start != EXTENT_MAP_HOLE, en fs/btrfs/extent_io.c:1385 ------------[ cortar aqu\u00ed ]------------ ERROR del kernel en fs /btrfs/extent_io.c:1385! c\u00f3digo de operaci\u00f3n no v\u00e1lido: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: cargado Contaminado: GW 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Seguimiento de llamadas: \u0026lt; TAREA\u0026gt; extensi\u00f3n_write_cache_pages+0x2ac/0x8f0 extensi\u00f3n_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_ca che+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813 /0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Esto sucede porque no logramos escribir el espacio libre en cach\u00e9 en una instancia, volvemos e intentamos escribirlo nuevamente. Sin embargo, en el segundo paso, llamamos a btrfs_get_extent() en el inodo para obtener el mapeo de extensi\u00f3n. Debido a que este es un nuevo grupo de bloques, y con el inodo de espacio libre siempre buscamos la ra\u00edz de confirmaci\u00f3n para evitar un punto muerto con el \u00e1rbol, no encontramos nada y devolvemos un EXTENT_MAP_HOLE para el rango solicitado. Esto sucede porque la primera vez que intentamos escribir el cach\u00e9 de espacio, encontramos un error y, en caso de error, descartamos la asignaci\u00f3n de extensi\u00f3n. Esto es normal para archivos normales, pero el inodo de cach\u00e9 de espacio libre es especial. Siempre esperamos que el mapa de extensi\u00f3n sea correcto. Por lo tanto, la segunda vez terminamos con un mapa de extensi\u00f3n falso. Dado que estamos desaprobando esta funci\u00f3n, la forma m\u00e1s sencilla de solucionarlo es simplemente omitir la eliminaci\u00f3n del rango del mapa de extensi\u00f3n para este rango fallido. Acort\u00e9 la prueba usando inyecci\u00f3n de error para enfatizar el \u00e1rea y facilitar su reproducci\u00f3n. Con este parche implementado, ya no entraremos en p\u00e1nico con mi prueba de inyecci\u00f3n de errores."
    }
  ],
  "id": "CVE-2024-26726",
  "lastModified": "2025-07-10T15:15:23.733",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2024-04-03T15:15:54.313",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/143842584c1237ebc248b2547c29d16bbe400a92"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-617"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.