CVE-2025-38067

{"id": "CVE-2025-38067", "cveTags": [], "metrics": {}, "published": "2025-06-18T10:15:39.780", "references": [{"url": "https://git.kernel.org/stable/c/2df285dab00fa03a3ef939b6cb0d0d0aeb0791db", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/3e4028ef31b69286c9d4878cee0330235f53f218", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/48900d839a3454050fd5822e34be8d54c4ec9b86", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/b2b05d0dc2f4f0646922068af435aed5763d16ba", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/eaf112069a904b6207b4106ff083e0208232a2eb", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/f004f58d18a2d3dc761cf973ad27b4a5997bd876", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/fd881d0a085fc54354414aed990ccf05f282ba53", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrseq: Fix segfault on registration when rseq_cs is non-zero\n\nThe rseq_cs field is documented as being set to 0 by user-space prior to\nregistration, however this is not currently enforced by the kernel. This\ncan result in a segfault on return to user-space if the value stored in\nthe rseq_cs field doesn't point to a valid struct rseq_cs.\n\nThe correct solution to this would be to fail the rseq registration when\nthe rseq_cs field is non-zero. However, some older versions of glibc\nwill reuse the rseq area of previous threads without clearing the\nrseq_cs field and will also terminate the process if the rseq\nregistration fails in a secondary thread. This wasn't caught in testing\nbecause in this case the leftover rseq_cs does point to a valid struct\nrseq_cs.\n\nWhat we can do is clear the rseq_cs field on registration when it's\nnon-zero which will prevent segfaults on registration and won't break\nthe glibc versions that reuse rseq areas on thread creation."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rseq: Arreglar violaci\u00f3n de segmentaci\u00f3n en el registro cuando rseq_cs no es cero El campo rseq_cs est\u00e1 documentado como establecido a 0 por el espacio de usuario antes del registro, sin embargo esto no es aplicado actualmente por el kernel. Esto puede resultar en una violaci\u00f3n de segmentaci\u00f3n al regresar al espacio de usuario si el valor almacenado en el campo rseq_cs no apunta a una estructura rseq_cs v\u00e1lida. La soluci\u00f3n correcta para esto ser\u00eda fallar el registro de rseq cuando el campo rseq_cs no es cero. Sin embargo, algunas versiones anteriores de glibc reutilizar\u00e1n el \u00e1rea rseq de subprocesos anteriores sin borrar el campo rseq_cs y tambi\u00e9n terminar\u00e1n el proceso si el registro de rseq falla en un subproceso secundario. Esto no fue detectado en las pruebas porque en este caso el rseq_cs restante apunta a una estructura rseq_cs v\u00e1lida. Lo que podemos hacer es borrar el campo rseq_cs durante el registro cuando no sea cero, lo que evitar\u00e1 errores de segmentaci\u00f3n en el registro y no da\u00f1ar\u00e1 las versiones de glibc que reutilizan \u00e1reas rseq en la creaci\u00f3n de subprocesos."}], "lastModified": "2025-07-17T17:15:36.333", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}