CVE-2025-38210

{"id": "CVE-2025-38210", "cveTags": [], "metrics": {}, "published": "2025-07-04T14:15:29.207", "references": [{"url": "https://git.kernel.org/stable/c/015f04ac884a454d4d8aaa7b67758f047742b1cf", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/cefbafcbdef011d6ef9414902311afdfba3c33eb", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/fba4ceaa242d2bdf4c04b77bda41d32d02d3925d", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs-tsm-report: Fix NULL dereference of tsm_ops\n\nUnlike sysfs, the lifetime of configfs objects is controlled by\nuserspace. There is no mechanism for the kernel to find and delete all\ncreated config-items. Instead, the configfs-tsm-report mechanism has an\nexpectation that tsm_unregister() can happen at any time and cause\nestablished config-item access to start failing.\n\nThat expectation is not fully satisfied. While tsm_report_read(),\ntsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail\nif tsm_ops have been unregistered, tsm_report_privlevel_store()\ntsm_report_provider_show() fail to check for ops registration. Add the\nmissing checks for tsm_ops having been removed.\n\nNow, in supporting the ability for tsm_unregister() to always succeed,\nit leaves the problem of what to do with lingering config-items. The\nexpectation is that the admin that arranges for the ->remove() (unbind)\nof the ${tsm_arch}-guest driver is also responsible for deletion of all\nopen config-items. Until that deletion happens, ->probe() (reload /\nbind) of the ${tsm_arch}-guest driver fails.\n\nThis allows for emergency shutdown / revocation of attestation\ninterfaces, and requires coordinated restart."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: configfs-tsm-report: Arregla la desreferencia NULL de tsm_ops A diferencia de sysfs, el tiempo de vida de los objetos configfs est\u00e1 controlado por el espacio de usuario. No hay ning\u00fan mecanismo para que el kernel encuentre y elimine todos los elementos de configuraci\u00f3n creados. En cambio, el mecanismo configfs-tsm-report tiene una expectativa de que tsm_unregister() puede suceder en cualquier momento y hacer que el acceso establecido a los elementos de configuraci\u00f3n empiece a fallar. Esa expectativa no se cumple por completo. Mientras que tsm_report_read(), tsm_report_{is,is_bin}_visible() y tsm_report_make_item() fallan de forma segura si se ha anulado el registro de tsm_ops, tsm_report_privlevel_store() y tsm_report_provider_show() no comprueban el registro de operaciones. A\u00f1ade las comprobaciones que faltan para que se hayan eliminado los tsm_ops. Ahora, al permitir que tsm_unregister() siempre se ejecute correctamente, se plantea el problema de qu\u00e9 hacer con los elementos de configuraci\u00f3n persistentes. Se espera que el administrador que gestiona la eliminaci\u00f3n del controlador invitado ${tsm_arch} tambi\u00e9n sea responsable de eliminar todos los elementos de configuraci\u00f3n abiertos. Hasta que se elimine, la recarga y la vinculaci\u00f3n del controlador invitado ${tsm_arch} falla. Esto permite el apagado o la revocaci\u00f3n de emergencia de las interfaces de atestaci\u00f3n y requiere un reinicio coordinado."}], "lastModified": "2025-07-08T16:18:53.607", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}