cve-2024-35784
Vulnerability from cvelistv5
Published
2024-05-17 12:24
Modified
2024-11-05 09:22
Severity ?
Summary
btrfs: fix deadlock with fiemap and extent locking
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf
Impacted products
Vendor Product Version
Linux Linux
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T03:21:47.398Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-35784",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T15:42:57.457443Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-11T17:32:52.968Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "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": "ded566b4637f",
              "status": "affected",
              "version": "1da177e4c3f4",
              "versionType": "git"
            },
            {
              "lessThan": "89bca7fe6382",
              "status": "affected",
              "version": "1da177e4c3f4",
              "versionType": "git"
            },
            {
              "lessThan": "b0ad381fa769",
              "status": "affected",
              "version": "1da177e4c3f4",
              "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": [
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.24",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.7.*",
              "status": "unaffected",
              "version": "6.7.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.8",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock with fiemap and extent locking\n\nWhile working on the patchset to remove extent locking I got a lockdep\nsplat with fiemap and pagefaulting with my new extent lock replacement\nlock.\n\nThis deadlock exists with our normal code, we just don\u0027t have lockdep\nannotations with the extent locking so we\u0027ve never noticed it.\n\nSince we\u0027re copying the fiemap extent to user space on every iteration\nwe have the chance of pagefaulting.  Because we hold the extent lock for\nthe entire range we could mkwrite into a range in the file that we have\nmmap\u0027ed.  This would deadlock with the following stack trace\n\n[\u003c0\u003e] lock_extent+0x28d/0x2f0\n[\u003c0\u003e] btrfs_page_mkwrite+0x273/0x8a0\n[\u003c0\u003e] do_page_mkwrite+0x50/0xb0\n[\u003c0\u003e] do_fault+0xc1/0x7b0\n[\u003c0\u003e] __handle_mm_fault+0x2fa/0x460\n[\u003c0\u003e] handle_mm_fault+0xa4/0x330\n[\u003c0\u003e] do_user_addr_fault+0x1f4/0x800\n[\u003c0\u003e] exc_page_fault+0x7c/0x1e0\n[\u003c0\u003e] asm_exc_page_fault+0x26/0x30\n[\u003c0\u003e] rep_movs_alternative+0x33/0x70\n[\u003c0\u003e] _copy_to_user+0x49/0x70\n[\u003c0\u003e] fiemap_fill_next_extent+0xc8/0x120\n[\u003c0\u003e] emit_fiemap_extent+0x4d/0xa0\n[\u003c0\u003e] extent_fiemap+0x7f8/0xad0\n[\u003c0\u003e] btrfs_fiemap+0x49/0x80\n[\u003c0\u003e] __x64_sys_ioctl+0x3e1/0xb50\n[\u003c0\u003e] do_syscall_64+0x94/0x1a0\n[\u003c0\u003e] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nI wrote an fstest to reproduce this deadlock without my replacement lock\nand verified that the deadlock exists with our existing locking.\n\nTo fix this simply don\u0027t take the extent lock for the entire duration of\nthe fiemap.  This is safe in general because we keep track of where we\nare when we\u0027re searching the tree, so if an ordered extent updates in\nthe middle of our fiemap call we\u0027ll still emit the correct extents\nbecause we know what offset we were on before.\n\nThe only place we maintain the lock is searching delalloc.  Since the\ndelalloc stuff can change during writeback we want to lock the extent\nrange so we have a consistent view of delalloc at the time we\u0027re\nchecking to see if we need to set the delalloc flag.\n\nWith this patch applied we no longer deadlock with my testcase."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-11-05T09:22:17.865Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf"
        },
        {
          "url": "https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b"
        },
        {
          "url": "https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd"
        }
      ],
      "title": "btrfs: fix deadlock with fiemap and extent locking",
      "x_generator": {
        "engine": "bippy-9e1c9544281a"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-35784",
    "datePublished": "2024-05-17T12:24:24.421Z",
    "dateReserved": "2024-05-17T12:19:12.337Z",
    "dateUpdated": "2024-11-05T09:22:17.865Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-35784\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-05-17T13:15:58.270\",\"lastModified\":\"2024-11-21T09:20:53.293\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: fix deadlock with fiemap and extent locking\\n\\nWhile working on the patchset to remove extent locking I got a lockdep\\nsplat with fiemap and pagefaulting with my new extent lock replacement\\nlock.\\n\\nThis deadlock exists with our normal code, we just don\u0027t have lockdep\\nannotations with the extent locking so we\u0027ve never noticed it.\\n\\nSince we\u0027re copying the fiemap extent to user space on every iteration\\nwe have the chance of pagefaulting.  Because we hold the extent lock for\\nthe entire range we could mkwrite into a range in the file that we have\\nmmap\u0027ed.  This would deadlock with the following stack trace\\n\\n[\u003c0\u003e] lock_extent+0x28d/0x2f0\\n[\u003c0\u003e] btrfs_page_mkwrite+0x273/0x8a0\\n[\u003c0\u003e] do_page_mkwrite+0x50/0xb0\\n[\u003c0\u003e] do_fault+0xc1/0x7b0\\n[\u003c0\u003e] __handle_mm_fault+0x2fa/0x460\\n[\u003c0\u003e] handle_mm_fault+0xa4/0x330\\n[\u003c0\u003e] do_user_addr_fault+0x1f4/0x800\\n[\u003c0\u003e] exc_page_fault+0x7c/0x1e0\\n[\u003c0\u003e] asm_exc_page_fault+0x26/0x30\\n[\u003c0\u003e] rep_movs_alternative+0x33/0x70\\n[\u003c0\u003e] _copy_to_user+0x49/0x70\\n[\u003c0\u003e] fiemap_fill_next_extent+0xc8/0x120\\n[\u003c0\u003e] emit_fiemap_extent+0x4d/0xa0\\n[\u003c0\u003e] extent_fiemap+0x7f8/0xad0\\n[\u003c0\u003e] btrfs_fiemap+0x49/0x80\\n[\u003c0\u003e] __x64_sys_ioctl+0x3e1/0xb50\\n[\u003c0\u003e] do_syscall_64+0x94/0x1a0\\n[\u003c0\u003e] entry_SYSCALL_64_after_hwframe+0x6e/0x76\\n\\nI wrote an fstest to reproduce this deadlock without my replacement lock\\nand verified that the deadlock exists with our existing locking.\\n\\nTo fix this simply don\u0027t take the extent lock for the entire duration of\\nthe fiemap.  This is safe in general because we keep track of where we\\nare when we\u0027re searching the tree, so if an ordered extent updates in\\nthe middle of our fiemap call we\u0027ll still emit the correct extents\\nbecause we know what offset we were on before.\\n\\nThe only place we maintain the lock is searching delalloc.  Since the\\ndelalloc stuff can change during writeback we want to lock the extent\\nrange so we have a consistent view of delalloc at the time we\u0027re\\nchecking to see if we need to set the delalloc flag.\\n\\nWith this patch applied we no longer deadlock with my testcase.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: btrfs: soluciona el punto muerto con fiemap y bloqueo de extensi\u00f3n Mientras trabajaba en el conjunto de parches para eliminar el bloqueo de extensi\u00f3n, obtuve un lockdep splat con fiemap y pagefaulting con mi nuevo bloqueo de reemplazo de bloqueo de extensi\u00f3n. Este punto muerto existe con nuestro c\u00f3digo normal, simplemente no tenemos anotaciones de bloqueo con el bloqueo de extensi\u00f3n, por lo que nunca lo hemos notado. Dado que copiamos la extensi\u00f3n del mapa de archivos al espacio del usuario en cada iteraci\u00f3n, tenemos la posibilidad de que se produzcan errores de p\u00e1gina. Debido a que mantenemos el bloqueo de extensi\u00f3n para todo el rango, podemos escribir en un rango en el archivo que hemos asignado. Esto se bloquear\u00eda con el siguiente seguimiento de pila [\u0026lt;0\u0026gt;] lock_extent+0x28d/0x2f0 [\u0026lt;0\u0026gt;] btrfs_page_mkwrite+0x273/0x8a0 [\u0026lt;0\u0026gt;] do_page_mkwrite+0x50/0xb0 [\u0026lt;0\u0026gt;] do_fault+0xc1/0x7b0 [\u0026lt; 0\u0026gt;] __handle_mm_fault+0x2fa/0x460 [\u0026lt;0\u0026gt;] handle_mm_fault+0xa4/0x330 [\u0026lt;0\u0026gt;] do_user_addr_fault+0x1f4/0x800 [\u0026lt;0\u0026gt;] exc_page_fault+0x7c/0x1e0 [\u0026lt;0\u0026gt;] asm_exc_page_fault+0x26/0x30 [\u0026lt; 0\u0026gt;] rep_movs_alternative+0x33/0x70 [\u0026lt;0\u0026gt;] _copy_to_user+0x49/0x70 [\u0026lt;0\u0026gt;] fiemap_fill_next_extent+0xc8/0x120 [\u0026lt;0\u0026gt;] emit_fiemap_extent+0x4d/0xa0 [\u0026lt;0\u0026gt;] extend_fiemap+0x7f8/0xad0 [\u0026lt; 0\u0026gt;] btrfs_fiemap+0x49/0x80 [\u0026lt;0\u0026gt;] __x64_sys_ioctl+0x3e1/0xb50 [\u0026lt;0\u0026gt;] do_syscall_64+0x94/0x1a0 [\u0026lt;0\u0026gt;] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Escrib\u00ed un fstest para reproducir este interbloqueo sin mi bloqueo de reemplazo y verifiqu\u00e9 que existe un punto muerto con nuestro bloqueo existente. Para solucionar este problema, simplemente no utilice el bloqueo de extensi\u00f3n durante toda la duraci\u00f3n del mapa de archivos. En general, esto es seguro porque realizamos un seguimiento de d\u00f3nde estamos cuando buscamos en el \u00e1rbol, por lo que si una extensi\u00f3n ordenada se actualiza en medio de nuestra llamada a fiemap, seguiremos emitiendo las extensiones correctas porque sabemos en qu\u00e9 desplazamiento est\u00e1bamos. antes. El \u00fanico lugar donde mantenemos el bloqueo es buscando en delalloc. Dado que las cosas de delalloc pueden cambiar durante la reescritura, queremos bloquear el rango de extensi\u00f3n para tener una vista consistente de delalloc en el momento en que verificamos si necesitamos configurar el indicador delalloc. Con este parche aplicado ya no nos estancamos con mi caso de prueba.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf\",\"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.