fkie_cve-2024-35798
Vulnerability from fkie_nvd
Published
2024-05-17 14:15
Modified
2024-11-21 09:20
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race in read_extent_buffer_pages() There are reports from tree-checker that detects corrupted nodes, without any obvious pattern so possibly an overwrite in memory. After some debugging it turns out there's a race when reading an extent buffer the uptodate status can be missed. To prevent concurrent reads for the same extent buffer, read_extent_buffer_pages() performs these checks: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) goto done; At this point, it seems safe to start the actual read operation. Once that completes, end_bbio_meta_read() does /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normally, this is enough to ensure only one read happens, and all other callers wait for it to finish before returning. Unfortunately, there is a racey interleaving: Thread A | Thread B | Thread C ---------+----------+--------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) When this happens, thread B kicks of an unnecessary read. Worse, thread C will see UPTODATE set and return immediately, while the read from thread B is still in progress. This race could result in tree-checker errors like this as the extent buffer is concurrently modified: BTRFS critical (device dm-0): corrupted node, root=256 block=8550954455682405139 owner mismatch, have 11858205567642294356 expect [256, 18446744073709551360] Fix it by testing UPTODATE again after setting the READING bit, and if it's been set, skip the unnecessary read. [ minor update of changelog ]
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215
Impacted products
Vendor Product Version


To clipboard 

{
   cveTags: [],
   descriptions: [
      {
         lang: "en",
         value: "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race in read_extent_buffer_pages()\n\nThere are reports from tree-checker that detects corrupted nodes,\nwithout any obvious pattern so possibly an overwrite in memory.\nAfter some debugging it turns out there's a race when reading an extent\nbuffer the uptodate status can be missed.\n\nTo prevent concurrent reads for the same extent buffer,\nread_extent_buffer_pages() performs these checks:\n\n    /* (1) */\n    if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags))\n        return 0;\n\n    /* (2) */\n    if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags))\n        goto done;\n\nAt this point, it seems safe to start the actual read operation. Once\nthat completes, end_bbio_meta_read() does\n\n    /* (3) */\n    set_extent_buffer_uptodate(eb);\n\n    /* (4) */\n    clear_bit(EXTENT_BUFFER_READING, &eb->bflags);\n\nNormally, this is enough to ensure only one read happens, and all other\ncallers wait for it to finish before returning.  Unfortunately, there is\na racey interleaving:\n\n    Thread A | Thread B | Thread C\n    ---------+----------+---------\n       (1)   |          |\n             |    (1)   |\n       (2)   |          |\n       (3)   |          |\n       (4)   |          |\n             |    (2)   |\n             |          |    (1)\n\nWhen this happens, thread B kicks of an unnecessary read. Worse, thread\nC will see UPTODATE set and return immediately, while the read from\nthread B is still in progress.  This race could result in tree-checker\nerrors like this as the extent buffer is concurrently modified:\n\n    BTRFS critical (device dm-0): corrupted node, root=256\n    block=8550954455682405139 owner mismatch, have 11858205567642294356\n    expect [256, 18446744073709551360]\n\nFix it by testing UPTODATE again after setting the READING bit, and if\nit's been set, skip the unnecessary read.\n\n[ minor update of changelog ]",
      },
      {
         lang: "es",
         value: "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la ejecución en read_extent_buffer_pages() Hay informes de tree-checker que detecta nodos corruptos, sin ningún patrón obvio por lo que posiblemente se sobrescriba en la memoria. Después de un poco de depuración, resulta que hay una ejecución cuando al leer un búfer de extensión se puede perder el estado de actualización. Para evitar lecturas simultáneas para el mismo búfer de extensión, read_extent_buffer_pages() realiza estas comprobaciones: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) ir a listo; En este punto, parece seguro iniciar la operación de lectura real. Una vez que se completa, end_bbio_meta_read() hace /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normalmente, esto es suficiente para garantizar que solo se realice una lectura y que todos los demás llamantes esperen a que finalice antes de regresar. Desafortunadamente, hay un entrelazado racial: Hilo A | Hilo B | Rosca C ---------+----------+----------------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) Cuando esto sucede, el hilo B inicia una lectura innecesaria. Peor aún, el subproceso C verá la ACTUALIZACIÓN configurada y regresará inmediatamente, mientras la lectura del subproceso B aún está en progreso. Esta ejecución podría dar como resultado errores del comprobador de árbol como este, ya que el búfer de extensión se modifica simultáneamente: BTRFS crítico (dispositivo dm-0): nodo dañado, raíz=256 bloque=8550954455682405139 el propietario no coincide, tiene 11858205567642294356 expect [256, 18446744073709551360] Arreglarlo probando UPTODATE nuevamente después de configurar el bit de LECTURA y, si se ha configurado, omita la lectura innecesaria. [actualización menor del registro de cambios]",
      },
   ],
   id: "CVE-2024-35798",
   lastModified: "2024-11-21T09:20:55.260",
   metrics: {},
   published: "2024-05-17T14:15:12.170",
   references: [
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         url: "https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         url: "https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         url: "https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         url: "https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         url: "https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         url: "https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         url: "https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80",
      },
      {
         source: "af854a3a-2127-422b-91ae-364da2661108",
         url: "https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215",
      },
   ],
   sourceIdentifier: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   vulnStatus: "Awaiting Analysis",
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



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.