CVE-2026-23207

{"id": "CVE-2026-23207", "cveTags": [], "metrics": {}, "published": "2026-02-14T17:15:58.610", "references": [{"url": "https://git.kernel.org/stable/c/2ac3a105e51496147c0e44e49466eecfcc532d57", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: tegra210-quad: Protect curr_xfer check in IRQ handler\n\nNow that all other accesses to curr_xfer are done under the lock,\nprotect the curr_xfer NULL check in tegra_qspi_isr_thread() with the\nspinlock. Without this protection, the following race can occur:\n\n CPU0 (ISR thread) CPU1 (timeout path)\n ---------------- -------------------\n if (!tqspi->curr_xfer)\n // sees non-NULL\n spin_lock()\n tqspi->curr_xfer = NULL\n spin_unlock()\n handle_*_xfer()\n spin_lock()\n t = tqspi->curr_xfer // NULL!\n ... t->len ... // NULL dereference!\n\nWith this patch, all curr_xfer accesses are now properly synchronized.\n\nAlthough all accesses to curr_xfer are done under the lock, in\ntegra_qspi_isr_thread() it checks for NULL, releases the lock and\nreacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer().\nThere is a potential for an update in between, which could cause a NULL\npointer dereference.\n\nTo handle this, add a NULL check inside the handlers after acquiring\nthe lock. This ensures that if the timeout path has already cleared\ncurr_xfer, the handler will safely return without dereferencing the\nNULL pointer."}, {"lang": "es", "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nspi: tegra210-quad: Proteger la comprobaci\u00f3n de curr_xfer en el manejador IRQ\n\nAhora que todos los dem\u00e1s accesos a curr_xfer se realizan bajo el bloqueo, proteger la comprobaci\u00f3n de NULL de curr_xfer en tegra_qspi_isr_thread() con el spinlock. Sin esta protecci\u00f3n, la siguiente condici\u00f3n de carrera puede ocurrir:\n\n CPU0 (hilo ISR) CPU1 (ruta de tiempo de espera)\n ---------------- -------------------\n if (!tqspi->curr_xfer)\n // ve no-NULL\n spin_lock()\n tqspi->curr_xfer = NULL\n spin_unlock()\n handle_*_xfer()\n spin_lock()\n t = tqspi->curr_xfer // \u00a1NULL!\n ... t->len ... // \u00a1Desreferencia de NULL!\n\nCon este parche, todos los accesos a curr_xfer est\u00e1n ahora correctamente sincronizados.\n\nAunque todos los accesos a curr_xfer se realizan bajo el bloqueo, en tegra_qspi_isr_thread() comprueba si es NULL, libera el bloqueo y lo vuelve a adquirir m\u00e1s tarde en handle_cpu_based_xfer()/handle_dma_based_xfer(). Existe la posibilidad de una actualizaci\u00f3n intermedia, lo que podr\u00eda causar una desreferencia de puntero NULL.\n\nPara manejar esto, a\u00f1adir una comprobaci\u00f3n de NULL dentro de los manejadores despu\u00e9s de adquirir el bloqueo. Esto asegura que si la ruta de tiempo de espera ya ha limpiado curr_xfer, el manejador regresar\u00e1 de forma segura sin desreferenciar el puntero NULL."}], "lastModified": "2026-02-18T17:52:22.253", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}