fkie_cve-2024-57942
Vulnerability from fkie_nvd
Published
2025-01-21 13:15
Modified
2025-01-21 13:15
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix ceph copy to cache on write-begin At the end of netfs_unlock_read_folio() in which folios are marked appropriately for copying to the cache (either with by being marked dirty and having their private data set or by having PG_private_2 set) and then unlocked, the folio_queue struct has the entry pointing to the folio cleared. This presents a problem for netfs_pgpriv2_write_to_the_cache(), which is used to write folios marked with PG_private_2 to the cache as it expects to be able to trawl the folio_queue list thereafter to find the relevant folios, leading to a hang. Fix this by not clearing the folio_queue entry if we're going to do the deprecated copy-to-cache. The clearance will be done instead as the folios are written to the cache. This can be reproduced by starting cachefiles, mounting a ceph filesystem with "-o fsc" and writing to it.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/38cf8e945721ffe708fa675507465da7f4f2a9f7
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/43b8d3249b0b71bad239d42dbe08ce6c938ba000
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix ceph copy to cache on write-begin\n\nAt the end of netfs_unlock_read_folio() in which folios are marked\nappropriately for copying to the cache (either with by being marked dirty\nand having their private data set or by having PG_private_2 set) and then\nunlocked, the folio_queue struct has the entry pointing to the folio\ncleared.  This presents a problem for netfs_pgpriv2_write_to_the_cache(),\nwhich is used to write folios marked with PG_private_2 to the cache as it\nexpects to be able to trawl the folio_queue list thereafter to find the\nrelevant folios, leading to a hang.\n\nFix this by not clearing the folio_queue entry if we\u0027re going to do the\ndeprecated copy-to-cache.  The clearance will be done instead as the folios\nare written to the cache.\n\nThis can be reproduced by starting cachefiles, mounting a ceph filesystem\nwith \"-o fsc\" and writing to it."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Fix ceph copy to cache on write-begin Al final de netfs_unlock_read_folio() en el que los folios se marcan adecuadamente para copiarlos al cach\u00e9 (ya sea marc\u00e1ndolos como sucios y teniendo sus datos privados configurados o teniendo PG_private_2 configurado) y luego se desbloquean, la estructura folio_queue tiene la entrada que apunta al folio borrada. Esto presenta un problema para netfs_pgpriv2_write_to_the_cache(), que se usa para escribir folios marcados con PG_private_2 en el cach\u00e9, ya que espera poder rastrear la lista folio_queue a partir de entonces para encontrar los folios relevantes, lo que lleva a un bloqueo. Solucione esto al no borrar la entrada folio_queue si vamos a hacer la copia al cach\u00e9 obsoleta. La limpieza se realizar\u00e1 en su lugar a medida que los folios se escriben en el cach\u00e9. Esto se puede reproducir iniciando cachefiles, montando un sistema de archivos ceph con \"-o fsc\" y escribiendo en \u00e9l."
    }
  ],
  "id": "CVE-2024-57942",
  "lastModified": "2025-01-21T13:15:08.743",
  "metrics": {},
  "published": "2025-01-21T13:15:08.743",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/38cf8e945721ffe708fa675507465da7f4f2a9f7"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/43b8d3249b0b71bad239d42dbe08ce6c938ba000"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.