fkie_cve-2025-21664
Vulnerability from fkie_nvd
Published
2025-01-21 13:15
Modified
2025-02-02 11:15
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
dm thin: make get_first_thin use rcu-safe list first function
The documentation in rculist.h explains the absence of list_empty_rcu()
and cautions programmers against relying on a list_empty() ->
list_first() sequence in RCU safe code. This is because each of these
functions performs its own READ_ONCE() of the list head. This can lead
to a situation where the list_empty() sees a valid list entry, but the
subsequent list_first() sees a different view of list head state after a
modification.
In the case of dm-thin, this author had a production box crash from a GP
fault in the process_deferred_bios path. This function saw a valid list
head in get_first_thin() but when it subsequently dereferenced that and
turned it into a thin_c, it got the inside of the struct pool, since the
list was now empty and referring to itself. The kernel on which this
occurred printed both a warning about a refcount_t being saturated, and
a UBSAN error for an out-of-bounds cpuid access in the queued spinlock,
prior to the fault itself. When the resulting kdump was examined, it
was possible to see another thread patiently waiting in thin_dtr's
synchronize_rcu.
The thin_dtr call managed to pull the thin_c out of the active thins
list (and have it be the last entry in the active_thins list) at just
the wrong moment which lead to this crash.
Fortunately, the fix here is straight forward. Switch get_first_thin()
function to use list_first_or_null_rcu() which performs just a single
READ_ONCE() and returns NULL if the list is already empty.
This was run against the devicemapper test suite's thin-provisioning
suites for delete and suspend and no regressions were observed.
References
Impacted products
Vendor | Product | Version |
---|
{ "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: make get_first_thin use rcu-safe list first function\n\nThe documentation in rculist.h explains the absence of list_empty_rcu()\nand cautions programmers against relying on a list_empty() -\u003e\nlist_first() sequence in RCU safe code. This is because each of these\nfunctions performs its own READ_ONCE() of the list head. This can lead\nto a situation where the list_empty() sees a valid list entry, but the\nsubsequent list_first() sees a different view of list head state after a\nmodification.\n\nIn the case of dm-thin, this author had a production box crash from a GP\nfault in the process_deferred_bios path. This function saw a valid list\nhead in get_first_thin() but when it subsequently dereferenced that and\nturned it into a thin_c, it got the inside of the struct pool, since the\nlist was now empty and referring to itself. The kernel on which this\noccurred printed both a warning about a refcount_t being saturated, and\na UBSAN error for an out-of-bounds cpuid access in the queued spinlock,\nprior to the fault itself. When the resulting kdump was examined, it\nwas possible to see another thread patiently waiting in thin_dtr\u0027s\nsynchronize_rcu.\n\nThe thin_dtr call managed to pull the thin_c out of the active thins\nlist (and have it be the last entry in the active_thins list) at just\nthe wrong moment which lead to this crash.\n\nFortunately, the fix here is straight forward. Switch get_first_thin()\nfunction to use list_first_or_null_rcu() which performs just a single\nREAD_ONCE() and returns NULL if the list is already empty.\n\nThis was run against the devicemapper test suite\u0027s thin-provisioning\nsuites for delete and suspend and no regressions were observed." }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm thin: hacer que get_first_thin use la funci\u00f3n list first de rcu-safe La documentaci\u00f3n en rculist.h explica la ausencia de list_empty_rcu() y advierte a los programadores que no conf\u00eden en una secuencia list_empty() -\u0026gt; list_first() en el c\u00f3digo seguro de RCU. Esto se debe a que cada una de estas funciones realiza su propio READ_ONCE() del encabezado de la lista. Esto puede llevar a una situaci\u00f3n en la que list_empty() ve una entrada de lista v\u00e1lida, pero el list_first() posterior ve una vista diferente del estado del encabezado de lista despu\u00e9s de una modificaci\u00f3n. En el caso de dm-thin, este autor tuvo un bloqueo del cuadro de producci\u00f3n debido a una falla de GP en la ruta process_deferred_bios. Esta funci\u00f3n vio un encabezado de lista v\u00e1lido en get_first_thin() pero cuando posteriormente desreferenciaba eso y lo convert\u00eda en un thin_c, obtuvo el interior del grupo de estructuras, ya que la lista ahora estaba vac\u00eda y se refer\u00eda a s\u00ed misma. El n\u00facleo en el que esto ocurri\u00f3 imprimi\u00f3 una advertencia sobre la saturaci\u00f3n de un refcount_t y un error UBSAN por un acceso a cpuid fuera de los l\u00edmites en el spinlock en cola, antes del fallo en s\u00ed. Cuando se examin\u00f3 el kdump resultante, fue posible ver otro hilo esperando pacientemente en elsynchronous_rcu de thin_dtr. La llamada thin_dtr logr\u00f3 sacar el thin_c de la lista de thins activa (y hacer que sea la \u00faltima entrada en la lista de active_thins) justo en el momento equivocado, lo que provoc\u00f3 este bloqueo. Afortunadamente, la soluci\u00f3n aqu\u00ed es sencilla. Cambie la funci\u00f3n get_first_thin() para usar list_first_or_null_rcu() que realiza solo un \u00fanico READ_ONCE() y devuelve NULL si la lista ya est\u00e1 vac\u00eda. Esto se ejecut\u00f3 contra las suites de aprovisionamiento fino del conjunto de pruebas devicemapper para eliminar y suspender y no se observaron regresiones." } ], "id": "CVE-2025-21664", "lastModified": "2025-02-02T11:15:15.697", "metrics": {}, "published": "2025-01-21T13:15:10.053", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/12771050b6d059eea096993bf2001da9da9fddff" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/6b305e98de0d225ccebfb225730a9f560d28ecb0" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/802666a40c71a23542c43a3f87e3a2d0f4e8fe45" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/80f130bfad1dab93b95683fc39b87235682b8f72" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/cbd0d5ecfa390ac29c5380200147d09c381b2ac6" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/cd30a3960433ec2db94b3689752fa3c5df44d649" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/ec037fe8c0d0f6140e3d8a49c7b29cb5582160b8" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" }
Loading…
Loading…
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.
Loading…
Loading…