fkie_cve-2024-47736
Vulnerability from fkie_nvd
Published
2024-10-21 13:15
Modified
2025-01-17 14: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: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy up `struct z_erofs_bvec`") for simplicity although it shouldn't be any difference.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29aPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8Patch
Impacted products
Vendor Product Version
linux linux_kernel *
linux linux_kernel *


To clipboard 

{
   configurations: [
      {
         nodes: [
            {
               cpeMatch: [
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "0FF7E6C3-354F-4036-93CB-2EE747BC3E8B",
                     versionEndExcluding: "6.10.13",
                     versionStartIncluding: "5.13",
                     vulnerable: true,
                  },
                  {
                     criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                     matchCriteriaId: "AB755D26-97F4-43B6-8604-CD076811E181",
                     versionEndExcluding: "6.11.2",
                     versionStartIncluding: "6.11",
                     vulnerable: true,
                  },
               ],
               negate: false,
               operator: "OR",
            },
         ],
      },
   ],
   cveTags: [],
   descriptions: [
      {
         lang: "en",
         value: "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: handle overlapped pclusters out of crafted images properly\n\nsyzbot reported a task hang issue due to a deadlock case where it is\nwaiting for the folio lock of a cached folio that will be used for\ncache I/Os.\n\nAfter looking into the crafted fuzzed image, I found it's formed with\nseveral overlapped big pclusters as below:\n\n Ext:   logical offset   |  length :     physical offset    |  length\n   0:        0..   16384 |   16384 :     151552..    167936 |   16384\n   1:    16384..   32768 |   16384 :     155648..    172032 |   16384\n   2:    32768..   49152 |   16384 :  537223168.. 537239552 |   16384\n...\n\nHere, extent 0/1 are physically overlapped although it's entirely\n_impossible_ for normal filesystem images generated by mkfs.\n\nFirst, managed folios containing compressed data will be marked as\nup-to-date and then unlocked immediately (unlike in-place folios) when\ncompressed I/Os are complete.  If physical blocks are not submitted in\nthe incremental order, there should be separate BIOs to avoid dependency\nissues.  However, the current code mis-arranges z_erofs_fill_bio_vec()\nand BIO submission which causes unexpected BIO waits.\n\nSecond, managed folios will be connected to their own pclusters for\nefficient inter-queries.  However, this is somewhat hard to implement\neasily if overlapped big pclusters exist.  Again, these only appear in\nfuzzed images so let's simply fall back to temporary short-lived pages\nfor correctness.\n\nAdditionally, it justifies that referenced managed folios cannot be\ntruncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy\nup `struct z_erofs_bvec`\") for simplicity although it shouldn't be any\ndifference.",
      },
      {
         lang: "es",
         value: "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: manejar pclusters superpuestos fuera de imágenes manipuladas correctamente syzbot informó un problema de bloqueo de tareas debido a un caso de interbloqueo donde está esperando el bloqueo de folio de un folio en caché que se usará para E/S de caché. Después de mirar la imagen difusa creada, encontré que está formada con varios pclusters grandes superpuestos como se muestra a continuación: Ext: desplazamiento lógico | longitud: desplazamiento físico | longitud 0: 0.. 16384 | 16384: 151552.. 167936 | 16384 1: 16384.. 32768 | 16384: 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Aquí, las extensiones 0/1 están físicamente superpuestas, aunque es completamente _impossible_ para las imágenes de sistemas de archivos normales generadas por mkfs. Primero, los folios administrados que contienen datos comprimidos se marcarán como actualizados y luego se desbloquearán inmediatamente (a diferencia de los folios locales) cuando se completen las E/S comprimidas. Si los bloques físicos no se envían en el orden incremental, debe haber BIO separados para evitar problemas de dependencia. Sin embargo, el código actual organiza mal z_erofs_fill_bio_vec() y el envío de BIO, lo que causa esperas inesperadas de BIO. En segundo lugar, los folios administrados se conectarán a sus propios pclusters para realizar consultas entre consultas eficientes. Sin embargo, esto es algo difícil de implementar fácilmente si existen pclusters grandes superpuestos. Nuevamente, estos solo aparecen en imágenes difusas, por lo que simplemente retrocedamos a páginas temporales de corta duración para que sean correctas. Además, justifica que los folios administrados referenciados no se pueden truncar por ahora y revierte parte de el commit 2080ca1ed3e4 (\"erofs: ordenar `struct z_erofs_bvec`\") para simplificar, aunque no debería haber ninguna diferencia.",
      },
   ],
   id: "CVE-2024-47736",
   lastModified: "2025-01-17T14:15:31.577",
   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-10-21T13:15:03.737",
   references: [
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         url: "https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50",
      },
      {
         source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
         tags: [
            "Patch",
         ],
         url: "https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8",
      },
   ],
   sourceIdentifier: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   vulnStatus: "Modified",
   weaknesses: [
      {
         description: [
            {
               lang: "en",
               value: "CWE-667",
            },
         ],
         source: "nvd@nist.gov",
         type: "Primary",
      },
   ],
}


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.