FKIE_CVE-2026-74686

Vulnerability from fkie_nvd - Published: 2026-08-22 16:16 - Updated: 2026-10-14 13:10
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved: rqspinlock: Reset tail when preserving queue on deadlock Currently, the destruction of the waiter queue is suppressed for rqspinlock in cases where a deadlock is detected. Deadlock checks happen relatively frequently (on entry for AA, within 1ms for ABBA), and waiter threads may not be involved in locking scenarios involving deadlocks. Thus, it is useful to not flush the queue and let other waiters take a stab at acquiring the lock after we detect a deadlock and exit. However, we need to follow the same logic as what we did previously for the waitq_timeout label: reset the tail, and if we cannot, signal the next waiter appropriately. In case of deadlocks, this signal would just mark the MCS node as unlocked, and in case of timeouts, it would signal RES_TIMEOUT_VAL. The difference thus is in the value propagated, which decides whether the queue remains active or gets flushed. Not doing the tail reset, and waiting for the next waiter can lead to cases where we are the final waiter, and thus no next waiter arrives, leading to intermittent stalls in this path. Once the next waiter does join, we will be unblocked. In the theoretical case when the next waiter never joins, we risk stalling indefinitely. This can only happen for ABBA deadlocks, since entry into the wait queue is guarded with AA checks. A precise sequence of executions leading up to this scenario can be: CPU 0 holds lock A. CPU 1 holds lock B. CPU 2 attempts lock B, becomes the pending waiter for B. CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues. CPU 1 attempts lock A. CPU 0 detects an ABBA deadlock. Once deadlock detection happens for CPU 0, it will sit waiting for the next waiter in the queue to populate node->next, which will experience delays until such a waiter arrives. Fix this by adjusting the logic for the check for deadlocks preceding the waitq_timeout label. It would make sense to consolidate code for both cases and use 'ret' to distinguish the value being propagated, but that is left as an exercise for a future refactoring task to avoid diff noise in this patch.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7a3c0289c3c8eb4607dff448ae9ff9f902c813af
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f54667b0c16213285c9d9b8e3929f738b8f71826
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/rqspinlock.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "f54667b0c16213285c9d9b8e3929f738b8f71826",
              "status": "affected",
              "version": "7bd6e5ce5be666fb3fb873bf20f77e62555b7835",
              "versionType": "git"
            },
            {
              "lessThan": "7a3c0289c3c8eb4607dff448ae9ff9f902c813af",
              "status": "affected",
              "version": "7bd6e5ce5be666fb3fb873bf20f77e62555b7835",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/rqspinlock.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.19"
            },
            {
              "lessThan": "6.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.9",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrqspinlock: Reset tail when preserving queue on deadlock\n\nCurrently, the destruction of the waiter queue is suppressed for\nrqspinlock in cases where a deadlock is detected. Deadlock checks happen\nrelatively frequently (on entry for AA, within 1ms for ABBA), and waiter\nthreads may not be involved in locking scenarios involving deadlocks.\nThus, it is useful to not flush the queue and let other waiters take a\nstab at acquiring the lock after we detect a deadlock and exit.\n\nHowever, we need to follow the same logic as what we did previously for\nthe waitq_timeout label: reset the tail, and if we cannot, signal the\nnext waiter appropriately. In case of deadlocks, this signal would just\nmark the MCS node as unlocked, and in case of timeouts, it would signal\nRES_TIMEOUT_VAL. The difference thus is in the value propagated, which\ndecides whether the queue remains active or gets flushed.\n\nNot doing the tail reset, and waiting for the next waiter can lead to\ncases where we are the final waiter, and thus no next waiter arrives,\nleading to intermittent stalls in this path. Once the next waiter does\njoin, we will be unblocked. In the theoretical case when the next waiter\nnever joins, we risk stalling indefinitely.\n\nThis can only happen for ABBA deadlocks, since entry into the wait queue\nis guarded with AA checks. A precise sequence of executions leading up\nto this scenario can be:\n\nCPU 0 holds lock A.\nCPU 1 holds lock B.\nCPU 2 attempts lock B, becomes the pending waiter for B.\nCPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues.\nCPU 1 attempts lock A.\nCPU 0 detects an ABBA deadlock.\n\nOnce deadlock detection happens for CPU 0, it will sit waiting for the\nnext waiter in the queue to populate node-\u003enext, which will experience\ndelays until such a waiter arrives.\n\nFix this by adjusting the logic for the check for deadlocks preceding\nthe waitq_timeout label. It would make sense to consolidate code for\nboth cases and use \u0027ret\u0027 to distinguish the value being propagated, but\nthat is left as an exercise for a future refactoring task to avoid diff\nnoise in this patch."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nrqspinlock: Reiniciar el final al preservar la cola en caso de interbloqueo\n\nActualmente, la destrucci\u00f3n de la cola de espera se suprime para rqspinlock en los casos en que se detecta un interbloqueo. Las comprobaciones de interbloqueo ocurren con relativa frecuencia (al entrar para AA, dentro de 1ms para ABBA), y los hilos de espera pueden no estar involucrados en escenarios de bloqueo que implican interbloqueos. Por lo tanto, es \u00fatil no vaciar la cola y permitir que otros hilos de espera intenten adquirir el bloqueo despu\u00e9s de que detectemos un interbloqueo y salgamos.\n\nSin embargo, necesitamos seguir la misma l\u00f3gica que la que hicimos previamente para la etiqueta waitq_timeout: reiniciar el final, y si no podemos, se\u00f1alar al siguiente hilo de espera apropiadamente. En caso de interbloqueos, esta se\u00f1al simplemente marcar\u00eda el nodo MCS como desbloqueado, y en caso de tiempos de espera, se\u00f1alar\u00eda RES_TIMEOUT_VAL. La diferencia, por lo tanto, radica en el valor propagado, que decide si la cola permanece activa o se vac\u00eda.\n\nNo realizar el reinicio del final, y esperar al siguiente hilo de espera puede llevar a casos en los que somos el \u00faltimo hilo de espera, y, por lo tanto, no llega ning\u00fan siguiente hilo de espera, lo que provoca bloqueos intermitentes en esta ruta. Una vez que el siguiente hilo de espera se une, seremos desbloqueados. En el caso te\u00f3rico cuando el siguiente hilo de espera nunca se une, corremos el riesgo de un bloqueo indefinido.\n\nEsto solo puede ocurrir para interbloqueos ABBA, ya que la entrada a la cola de espera est\u00e1 protegida con comprobaciones AA. Una secuencia precisa de ejecuciones que conduce a este escenario puede ser:\n\nLa CPU 0 mantiene el bloqueo A.\nLa CPU 1 mantiene el bloqueo B.\nLa CPU 2 intenta el bloqueo B, se convierte en el hilo de espera pendiente para B.\nLa CPU 0 intenta el bloqueo B. B tiene los bits de bloqueado+pendiente establecidos, por lo tanto, la CPU 0 se encola.\nLa CPU 1 intenta el bloqueo A.\nLa CPU 0 detecta un interbloqueo ABBA.\n\nUna vez que la detecci\u00f3n de interbloqueo ocurre para la CPU 0, se quedar\u00e1 esperando al siguiente hilo de espera en la cola para poblar node -\u003e next, lo que experimentar\u00e1 retrasos hasta que llegue dicho hilo de espera.\n\nSolucione esto ajustando la l\u00f3gica para la comprobaci\u00f3n de interbloqueos que precede a la etiqueta waitq_timeout. Tendr\u00eda sentido consolidar el c\u00f3digo para ambos casos y usar \u0027ret\u0027 para distinguir el valor que se propaga, pero eso se deja como un ejercicio para una futura tarea de refactorizaci\u00f3n para evitar ruido en el diff de este parche."
    }
  ],
  "id": "CVE-2026-74686",
  "lastModified": "2026-10-14T13:10:00.187",
  "metrics": {},
  "published": "2026-08-22T16:16:42.973",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7a3c0289c3c8eb4607dff448ae9ff9f902c813af"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f54667b0c16213285c9d9b8e3929f738b8f71826"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.