cve-2024-27080
Vulnerability from cvelistv5
Published
2024-05-01 13:05
Modified
2024-12-19 08:54
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race when detecting delalloc ranges during fiemap For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). This however introduced a race that makes us miss delalloc ranges for file regions that are currently holes, so the caller of fiemap will not be aware that there's data for some file regions. This can be quite serious for some use cases - for example in coreutils versions before 9.0, the cp program used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file to the destination file in order to preserve holes (see the documentation for its --sparse command line option). This means that if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, which is effectively a data loss issue, if it happened to hit the race described below. The race happens like this: 1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that has delalloc in the file range [64M, 65M[, which is currently a hole; 2) Fiemap locks the inode in shared mode, then starts iterating the inode's subvolume tree searching for file extent items, without having the whole fiemap target range locked in the inode's io tree - the change introduced recently by commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). It only locks ranges in the io tree when it finds a hole or prealloc extent since that commit; 3) Note that fiemap clones each leaf before using it, and this is to avoid deadlocks when locking a file range in the inode's io tree and the fiemap buffer is memory mapped to some file, because writing to the page with btrfs_page_mkwrite() will wait on any ordered extent for the page's range and the ordered extent needs to lock the range and may need to modify the same leaf, therefore leading to a deadlock on the leaf; 4) While iterating the file extent items in the cloned leaf before finding the hole in the range [64M, 65M[, the delalloc in that range is flushed and its ordered extent completes - meaning the corresponding file extent item is in the inode's subvolume tree, but not present in the cloned leaf that fiemap is iterating over; 5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in the cloned leaf (or a file extent item with disk_bytenr == 0 in case the NO_HOLES feature is not enabled), it will lock that file range in the inode's io tree and then search for delalloc by checking for the EXTENT_DELALLOC bit in the io tree for that range and ordered extents (with btrfs_find_delalloc_in_range()). But it finds nothing since the delalloc in that range was already flushed and the ordered extent completed and is gone - as a result fiemap will not report that there's delalloc or an extent for the range [64M, 65M[, so user space will be mislead into thinking that there's a hole in that range. This could actually be sporadically triggered with test case generic/094 from fstests, which reports a missing extent/delalloc range like this: generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad) --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100 +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000 @@ -1,3 +1,9 @@ QA output created by 094 fiemap run with sync fiemap run without sync +ERROR: couldn't find extent at 7 +map is 'HHDDHPPDPHPH' +logical: [ 5.. 6] phys: ---truncated---
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3
Impacted products
Vendor Product Version
Linux Linux Version: 6.8
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-27080",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-05-28T17:43:15.725119Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-04T17:46:25.000Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T00:27:57.834Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/extent_io.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "49d640d2946c35a17b051d54171a032dd95b0f50",
              "status": "affected",
              "version": "ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf",
              "versionType": "git"
            },
            {
              "lessThan": "ced63fffd63072c0ca55d5a451010d71bf08c0b3",
              "status": "affected",
              "version": "b0ad381fa7690244802aed119b478b4bdafc31dd",
              "versionType": "git"
            },
            {
              "lessThan": "978b63f7464abcfd364a6c95f734282c50f3decf",
              "status": "affected",
              "version": "b0ad381fa7690244802aed119b478b4bdafc31dd",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/extent_io.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.8"
            },
            {
              "lessThan": "6.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.26",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.9",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race when detecting delalloc ranges during fiemap\n\nFor fiemap we recently stopped locking the target extent range for the\nwhole duration of the fiemap call, in order to avoid a deadlock in a\nscenario where the fiemap buffer happens to be a memory mapped range of\nthe same file. This use case is very unlikely to be useful in practice but\nit may be triggered by fuzz testing (syzbot, etc).\n\nThis however introduced a race that makes us miss delalloc ranges for\nfile regions that are currently holes, so the caller of fiemap will not\nbe aware that there\u0027s data for some file regions. This can be quite\nserious for some use cases - for example in coreutils versions before 9.0,\nthe cp program used fiemap to detect holes and data in the source file,\ncopying only regions with data (extents or delalloc) from the source file\nto the destination file in order to preserve holes (see the documentation\nfor its --sparse command line option). This means that if cp was used\nwith a source file that had delalloc in a hole, the destination file could\nend up without that data, which is effectively a data loss issue, if it\nhappened to hit the race described below.\n\nThe race happens like this:\n\n1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that\n   has delalloc in the file range [64M, 65M[, which is currently a hole;\n\n2) Fiemap locks the inode in shared mode, then starts iterating the\n   inode\u0027s subvolume tree searching for file extent items, without having\n   the whole fiemap target range locked in the inode\u0027s io tree - the\n   change introduced recently by commit b0ad381fa769 (\"btrfs: fix\n   deadlock with fiemap and extent locking\"). It only locks ranges in\n   the io tree when it finds a hole or prealloc extent since that\n   commit;\n\n3) Note that fiemap clones each leaf before using it, and this is to\n   avoid deadlocks when locking a file range in the inode\u0027s io tree and\n   the fiemap buffer is memory mapped to some file, because writing\n   to the page with btrfs_page_mkwrite() will wait on any ordered extent\n   for the page\u0027s range and the ordered extent needs to lock the range\n   and may need to modify the same leaf, therefore leading to a deadlock\n   on the leaf;\n\n4) While iterating the file extent items in the cloned leaf before\n   finding the hole in the range [64M, 65M[, the delalloc in that range\n   is flushed and its ordered extent completes - meaning the corresponding\n   file extent item is in the inode\u0027s subvolume tree, but not present in\n   the cloned leaf that fiemap is iterating over;\n\n5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in\n   the cloned leaf (or a file extent item with disk_bytenr == 0 in case\n   the NO_HOLES feature is not enabled), it will lock that file range in\n   the inode\u0027s io tree and then search for delalloc by checking for the\n   EXTENT_DELALLOC bit in the io tree for that range and ordered extents\n   (with btrfs_find_delalloc_in_range()). But it finds nothing since the\n   delalloc in that range was already flushed and the ordered extent\n   completed and is gone - as a result fiemap will not report that there\u0027s\n   delalloc or an extent for the range [64M, 65M[, so user space will be\n   mislead into thinking that there\u0027s a hole in that range.\n\nThis could actually be sporadically triggered with test case generic/094\nfrom fstests, which reports a missing extent/delalloc range like this:\n\n  generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)\n      --- tests/generic/094.out\t2020-06-10 19:29:03.830519425 +0100\n      +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad\t2024-02-28 11:00:00.381071525 +0000\n      @@ -1,3 +1,9 @@\n       QA output created by 094\n       fiemap run with sync\n       fiemap run without sync\n      +ERROR: couldn\u0027t find extent at 7\n      +map is \u0027HHDDHPPDPHPH\u0027\n      +logical: [       5..       6] phys:\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T08:54:00.811Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50"
        },
        {
          "url": "https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3"
        },
        {
          "url": "https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf"
        }
      ],
      "title": "btrfs: fix race when detecting delalloc ranges during fiemap",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-27080",
    "datePublished": "2024-05-01T13:05:02.022Z",
    "dateReserved": "2024-02-19T14:20:24.217Z",
    "dateUpdated": "2024-12-19T08:54:00.811Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-27080\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-05-01T13:15:51.497\",\"lastModified\":\"2024-11-21T09:03:49.183\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: fix race when detecting delalloc ranges during fiemap\\n\\nFor fiemap we recently stopped locking the target extent range for the\\nwhole duration of the fiemap call, in order to avoid a deadlock in a\\nscenario where the fiemap buffer happens to be a memory mapped range of\\nthe same file. This use case is very unlikely to be useful in practice but\\nit may be triggered by fuzz testing (syzbot, etc).\\n\\nThis however introduced a race that makes us miss delalloc ranges for\\nfile regions that are currently holes, so the caller of fiemap will not\\nbe aware that there\u0027s data for some file regions. This can be quite\\nserious for some use cases - for example in coreutils versions before 9.0,\\nthe cp program used fiemap to detect holes and data in the source file,\\ncopying only regions with data (extents or delalloc) from the source file\\nto the destination file in order to preserve holes (see the documentation\\nfor its --sparse command line option). This means that if cp was used\\nwith a source file that had delalloc in a hole, the destination file could\\nend up without that data, which is effectively a data loss issue, if it\\nhappened to hit the race described below.\\n\\nThe race happens like this:\\n\\n1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that\\n   has delalloc in the file range [64M, 65M[, which is currently a hole;\\n\\n2) Fiemap locks the inode in shared mode, then starts iterating the\\n   inode\u0027s subvolume tree searching for file extent items, without having\\n   the whole fiemap target range locked in the inode\u0027s io tree - the\\n   change introduced recently by commit b0ad381fa769 (\\\"btrfs: fix\\n   deadlock with fiemap and extent locking\\\"). It only locks ranges in\\n   the io tree when it finds a hole or prealloc extent since that\\n   commit;\\n\\n3) Note that fiemap clones each leaf before using it, and this is to\\n   avoid deadlocks when locking a file range in the inode\u0027s io tree and\\n   the fiemap buffer is memory mapped to some file, because writing\\n   to the page with btrfs_page_mkwrite() will wait on any ordered extent\\n   for the page\u0027s range and the ordered extent needs to lock the range\\n   and may need to modify the same leaf, therefore leading to a deadlock\\n   on the leaf;\\n\\n4) While iterating the file extent items in the cloned leaf before\\n   finding the hole in the range [64M, 65M[, the delalloc in that range\\n   is flushed and its ordered extent completes - meaning the corresponding\\n   file extent item is in the inode\u0027s subvolume tree, but not present in\\n   the cloned leaf that fiemap is iterating over;\\n\\n5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in\\n   the cloned leaf (or a file extent item with disk_bytenr == 0 in case\\n   the NO_HOLES feature is not enabled), it will lock that file range in\\n   the inode\u0027s io tree and then search for delalloc by checking for the\\n   EXTENT_DELALLOC bit in the io tree for that range and ordered extents\\n   (with btrfs_find_delalloc_in_range()). But it finds nothing since the\\n   delalloc in that range was already flushed and the ordered extent\\n   completed and is gone - as a result fiemap will not report that there\u0027s\\n   delalloc or an extent for the range [64M, 65M[, so user space will be\\n   mislead into thinking that there\u0027s a hole in that range.\\n\\nThis could actually be sporadically triggered with test case generic/094\\nfrom fstests, which reports a missing extent/delalloc range like this:\\n\\n  generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)\\n      --- tests/generic/094.out\\t2020-06-10 19:29:03.830519425 +0100\\n      +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad\\t2024-02-28 11:00:00.381071525 +0000\\n      @@ -1,3 +1,9 @@\\n       QA output created by 094\\n       fiemap run with sync\\n       fiemap run without sync\\n      +ERROR: couldn\u0027t find extent at 7\\n      +map is \u0027HHDDHPPDPHPH\u0027\\n      +logical: [       5..       6] phys:\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: btrfs: corrige la ejecuci\u00f3n al detectar rangos de delalloc durante fiemap Para fiemap recientemente dejamos de bloquear el rango de extensi\u00f3n objetivo durante toda la duraci\u00f3n de la llamada a fiemap, para evitar un punto muerto en un escenario donde el b\u00fafer fiemap resulta ser un rango mapeado en memoria del mismo archivo. Es muy poco probable que este caso de uso sea \u00fatil en la pr\u00e1ctica, pero puede activarse mediante pruebas difusas (syzbot, etc.). Sin embargo, esto introdujo una ejecuci\u00f3n que nos hace perder rangos de delalloc para regiones de archivos que actualmente est\u00e1n vac\u00edas, por lo que quien llama a fiemap no sabr\u00e1 que hay datos para algunas regiones de archivos. Esto puede ser bastante grave en algunos casos de uso; por ejemplo, en las versiones de Coreutils anteriores a la 9.0, el programa cp utilizaba fiemap para detectar agujeros y datos en el archivo de origen, copiando solo regiones con datos (extensiones o delalloc) del archivo de origen al destino. archivo para preservar los agujeros (consulte la documentaci\u00f3n para conocer su opci\u00f3n de l\u00ednea de comando --sparse). Esto significa que si se us\u00f3 cp con un archivo de origen que ten\u00eda delalloc en un agujero, el archivo de destino podr\u00eda terminar sin esos datos, lo que efectivamente es un problema de p\u00e9rdida de datos, si llegara a la ejecuci\u00f3n que se describe a continuaci\u00f3n. La ejecuci\u00f3n ocurre as\u00ed: 1) Se llama a Fiemap, sin el indicador FIEMAP_FLAG_SYNC, para un archivo que tiene delalloc en el rango de archivos [64M, 65M[, que actualmente es un agujero; 2) Fiemap bloquea el inodo en modo compartido, luego comienza a iterar el \u00e1rbol de subvolumen del inodo buscando elementos de extensi\u00f3n de archivo, sin tener todo el rango objetivo de fiemap bloqueado en el \u00e1rbol io del inodo - el cambio introducido recientemente por el commit b0ad381fa769 (\\\"btrfs: fix deadlock\\\" con fiemap y bloqueo de extensi\u00f3n\\\"). Solo bloquea rangos en el \u00e1rbol io cuando encuentra un agujero o una extensi\u00f3n de asignaci\u00f3n previa desde esa confirmaci\u00f3n; 3) Tenga en cuenta que fiemap clona cada hoja antes de usarla, y esto es para evitar interbloqueos al bloquear un rango de archivos en el \u00e1rbol io del inodo y el b\u00fafer de fiemap est\u00e1 asignado en memoria a alg\u00fan archivo, porque escribir en la p\u00e1gina con btrfs_page_mkwrite() esperar\u00e1 en cualquier extensi\u00f3n ordenada para el rango de la p\u00e1gina y la extensi\u00f3n ordenada necesita bloquear el rango y puede necesitar modificar la misma hoja, lo que lleva a un punto muerto en la hoja; 4) Mientras se iteran los elementos de extensi\u00f3n del archivo en la hoja clonada antes de encontrar el hueco en el rango [64M, 65M[, la delalloc en ese rango se vac\u00eda y su extensi\u00f3n ordenada se completa, lo que significa que el elemento de extensi\u00f3n del archivo correspondiente est\u00e1 en el \u00e1rbol de subvolumen del inodo. , pero no est\u00e1 presente en la hoja clonada sobre la que fiemap est\u00e1 iterando; 5) Cuando fiemap encuentra el agujero en el rango [64M, 65M[ al ver el espacio en la hoja clonada (o un elemento de extensi\u00f3n de archivo con disk_bytenr == 0 en caso de que la funci\u00f3n NO_HOLES no est\u00e9 habilitada), bloquear\u00e1 ese rango de archivos. en el \u00e1rbol io del inodo y luego busque delalloc verificando el bit EXTENT_DELALLOC en el \u00e1rbol io para ese rango y extensiones ordenadas (con btrfs_find_delalloc_in_range()). Pero no encuentra nada ya que la delalloc en ese rango ya se vaci\u00f3 y la extensi\u00f3n ordenada se complet\u00f3 y desapareci\u00f3; como resultado, fiemap no informar\u00e1 que hay delalloc o una extensi\u00f3n para el rango [64M, 65M[, por lo que el espacio del usuario ser\u00e1 enga\u00f1oso a pensar que hay un agujero en ese rango. En realidad, esto podr\u00eda activarse espor\u00e1dicamente con el caso de prueba generic/094 de fstests, que informa que falta un rango de extensi\u00f3n/delalloc como este: generic/094 2s ... - falta de coincidencia de salida (consulte /home/fdmanana/git/hub/xfstests/results //generic/094.out.bad) ---truncado---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}"
  }
}


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.