FKIE_CVE-2026-23287

Vulnerability from fkie_nvd - Published: 2026-03-25 11:16 - Updated: 2026-03-25 15:41
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: irqchip/sifive-plic: Fix frozen interrupt due to affinity setting PLIC ignores interrupt completion message for disabled interrupt, explained by the specification: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored. This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled(). However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt. This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt's affinity setting. The uart port becomes frozen almost instantaneously. Fix this by checking PLIC's enable bit instead of irqd_irq_disabled().
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1072020685f4b81f6efad3b412cdae0bd62bb043
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1883332bf21feb8871af09daf604fc4836a76925
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2edbd173309165d103be6c73bd83e459dc45ae7b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/686eb378a4a51aa967e08337dd59daade16aec0f
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8942fb1a5bc2dcbd88f7e656d109d42f778f298f
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f611791a927141d05d7030607dea6372311c1413
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/sifive-plic: Fix frozen interrupt due to affinity setting\n\nPLIC ignores interrupt completion message for disabled interrupt, explained\nby the specification:\n\n    The PLIC signals it has completed executing an interrupt handler by\n    writing the interrupt ID it received from the claim to the\n    claim/complete register. The PLIC does not check whether the completion\n    ID is the same as the last claim ID for that target. If the completion\n    ID does not match an interrupt source that is currently enabled for\n    the target, the completion is silently ignored.\n\nThis caused problems in the past, because an interrupt can be disabled\nwhile still being handled and plic_irq_eoi() had no effect. That was fixed\nby checking if the interrupt is disabled, and if so enable it, before\nsending the completion message. That check is done with irqd_irq_disabled().\n\nHowever, that is not sufficient because the enable bit for the handling\nhart can be zero despite irqd_irq_disabled(d) being false. This can happen\nwhen affinity setting is changed while a hart is still handling the\ninterrupt.\n\nThis problem is easily reproducible by dumping a large file to uart (which\ngenerates lots of interrupts) and at the same time keep changing the uart\ninterrupt\u0027s affinity setting. The uart port becomes frozen almost\ninstantaneously.\n\nFix this by checking PLIC\u0027s enable bit instead of irqd_irq_disabled()."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nirqchip/sifive-plic: Soluci\u00f3n para la interrupci\u00f3n congelada debido a la configuraci\u00f3n de afinidad\n\nPLIC ignora el mensaje de finalizaci\u00f3n de interrupci\u00f3n para interrupciones deshabilitadas, explicado por la especificaci\u00f3n:\n\n    El PLIC se\u00f1ala que ha completado la ejecuci\u00f3n de un gestor de interrupciones escribiendo el ID de interrupci\u00f3n que recibi\u00f3 de la solicitud en el registro de solicitud/finalizaci\u00f3n. El PLIC no verifica si el ID de finalizaci\u00f3n es el mismo que el \u00faltimo ID de solicitud para ese objetivo. Si el ID de finalizaci\u00f3n no coincide con una fuente de interrupci\u00f3n que est\u00e1 actualmente habilitada para el objetivo, la finalizaci\u00f3n es ignorada silenciosamente.\n\nEsto caus\u00f3 problemas en el pasado, porque una interrupci\u00f3n puede ser deshabilitada mientras a\u00fan est\u00e1 siendo gestionada y plic_irq_eoi() no ten\u00eda efecto. Eso se solucion\u00f3 verificando si la interrupci\u00f3n est\u00e1 deshabilitada, y si es as\u00ed, habilitarla, antes de enviar el mensaje de finalizaci\u00f3n. Esa verificaci\u00f3n se realiza con irqd_irq_disabled().\n\nSin embargo, eso no es suficiente porque el bit de habilitaci\u00f3n para el hart de gesti\u00f3n puede ser cero a pesar de que irqd_irq_disabled(d) sea falso. Esto puede ocurrir cuando la configuraci\u00f3n de afinidad se cambia mientras un hart todav\u00eda est\u00e1 gestionando la interrupci\u00f3n.\n\nEste problema es f\u00e1cilmente reproducible volcando un archivo grande a la uart (lo que genera muchas interrupciones) y al mismo tiempo seguir cambiando la configuraci\u00f3n de afinidad de la interrupci\u00f3n de la uart. El puerto de la uart se congela casi instant\u00e1neamente.\n\nSolucione esto verificando el bit de habilitaci\u00f3n del PLIC en lugar de irqd_irq_disabled()."
    }
  ],
  "id": "CVE-2026-23287",
  "lastModified": "2026-03-25T15:41:33.977",
  "metrics": {},
  "published": "2026-03-25T11:16:23.583",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1072020685f4b81f6efad3b412cdae0bd62bb043"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1883332bf21feb8871af09daf604fc4836a76925"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/2edbd173309165d103be6c73bd83e459dc45ae7b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/686eb378a4a51aa967e08337dd59daade16aec0f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/8942fb1a5bc2dcbd88f7e656d109d42f778f298f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f611791a927141d05d7030607dea6372311c1413"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.



Detection rules are retrieved from Rulezet.