CVE-2025-38554

{"id": "CVE-2025-38554", "cveTags": [], "metrics": {}, "published": "2025-08-19T17:15:31.510", "references": [{"url": "https://git.kernel.org/stable/c/1bcd236a2536a451e385f8d6d2bb589689ec812f", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/6e88fe54721dee17d3496bc998f0c7d243896348", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/9bbffee67ffd16360179327b57f3b1245579ef08", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped\n\nBy inducing delays in the right places, Jann Horn created a reproducer for\na hard to hit UAF issue that became possible after VMAs were allowed to be\nrecycled by adding SLAB_TYPESAFE_BY_RCU to their cache.\n\nRace description is borrowed from Jann's discovery report:\nlock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under\nrcu_read_lock(). At that point, the VMA may be concurrently freed, and it\ncan be recycled by another process. vma_start_read() then increments the\nvma->vm_refcnt (if it is in an acceptable range), and if this succeeds,\nvma_start_read() can return a recycled VMA.\n\nIn this scenario where the VMA has been recycled, lock_vma_under_rcu()\nwill then detect the mismatching ->vm_mm pointer and drop the VMA through\nvma_end_read(), which calls vma_refcount_put(). vma_refcount_put() drops\nthe refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. \nThis is wrong: It implicitly assumes that the caller is keeping the VMA's\nmm alive, but in this scenario the caller has no relation to the VMA's mm,\nso the rcuwait_wake_up() can cause UAF.\n\nThe diagram depicting the race:\nT1 T2 T3\n== == ==\nlock_vma_under_rcu\n mas_walk\n <VMA gets removed from mm>\n mmap\n <the same VMA is reallocated>\n vma_start_read\n __refcount_inc_not_zero_limited_acquire\n munmap\n __vma_enter_locked\n refcount_add_not_zero\n vma_end_read\n vma_refcount_put\n __refcount_dec_and_test\n rcuwait_wait_event\n <finish operation>\n rcuwait_wake_up [UAF]\n\nNote that rcuwait_wait_event() in T3 does not block because refcount was\nalready dropped by T1. At this point T3 can exit and free the mm causing\nUAF in T1.\n\nTo avoid this we move vma->vm_mm verification into vma_start_read() and\ngrab vma->vm_mm to stabilize it before vma_refcount_put() operation.\n\n[surenb@google.com: v3]"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: se corrige un UAF cuando vma-&gt;mm se libera despu\u00e9s de que vma-&gt;vm_refcnt se eliminara. Al inducir retrasos en los lugares adecuados, Jann Horn cre\u00f3 un reproductor para un problema de UAF dif\u00edcil de alcanzar que se hizo posible despu\u00e9s de que se permitiera reciclar los VMA agregando SLAB_TYPESAFE_BY_RCU a su cach\u00e9. La descripci\u00f3n de la ejecuci\u00f3n se tom\u00f3 prestada del informe de descubrimiento de Jann: lock_vma_under_rcu() busca un VMA sin bloqueo con mas_walk() bajo rcu_read_lock(). En ese punto, el VMA puede liberarse simult\u00e1neamente y puede reciclarse por otro proceso. vma_start_read() luego incrementa vma-&gt;vm_refcnt (si est\u00e1 en un rango aceptable) y, si esto tiene \u00e9xito, vma_start_read() puede devolver un VMA reciclado. En este escenario, donde el VMA se ha reciclado, lock_vma_under_rcu() detectar\u00e1 el puntero -&gt;vm_mm no coincidente y eliminar\u00e1 el VMA mediante vma_end_read(), que llama a vma_refcount_put(). vma_refcount_put() elimina el recuento de referencias y luego llama a rcuwait_wake_up() usando una copia de vma-&gt;vm_mm. Esto es incorrecto: asume impl\u00edcitamente que quien llama mantiene activo el mm del VMA, pero en este escenario, quien llama no tiene relaci\u00f3n con el mm del VMA, por lo que rcuwait_wake_up() puede causar UAF. El diagrama que representa la ejecuci\u00f3n: T1 T2 T3 == == == lock_vma_under_rcu mas_walk mmap vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event rcuwait_wake_up [UAF] Tenga en cuenta que rcuwait_wait_event() en T3 no se bloquea porque refcount ya fue descartado por T1. En este punto, T3 puede salir y liberar el mm que causa UAF en T1. Para evitar esto, movemos la verificaci\u00f3n vma-&gt;vm_mm a vma_start_read() y tomamos vma-&gt;vm_mm para estabilizarlo antes de la operaci\u00f3n vma_refcount_put(). [surenb@google.com: v3]"}], "lastModified": "2025-08-20T14:40:17.713", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}