Intel
    Ohne BewertungCVE-2026-98395

    Im Linux-Kernel wurde folgende Schwachstelle behoben: powerpc/entry: Behebung der Speicherbeschädigung von irq_soft_mask bei erneutem Ve…

    Veröffentlicht Zuletzt geändert Quellen: BSI, CVE.org

    Was ist betroffen, was ist zu tun

    Die vorliegenden Quellen nennen keine Fix-Version. Prüfen Sie die Herstellerhinweise in den Referenzen unten.

    Metriken

    —

    Priorität

    Für diese Schwachstelle liegt kein Wert vor.

    —

    CVSS v3

    Für diese Schwachstelle liegt kein Wert vor.

    0,2 %

    EPSS-Score

    Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.

    Quelle: FIRST EPSS, Perzentil 8,9 %

    Alle Metriken anzeigen
    Schweregrad
    Ohne Bewertung
    Priority-Score

    Der Priorisierungs-Score ist eine zusammengeführte Kennzahl, die mehrere Einzelsignale zu einer einzigen, handlungsleitenden Rangfolge verdichtet: technische Schwere (CVSS), Ausnutzungswahrscheinlichkeit (EPSS), der Status als bekannt ausgenutzt (KEV) und der Kontext des betroffenen Assets. Ziel ist die Antwort auf die einzig wirklich wichtige Frage im Schwachstellenmanagement: Was zuerst?

    Im Glossar lesen
    30.63
    Exploit-Reife

    Ein Exploit ist Code oder eine Technik, die eine konkrete Schwachstelle gezielt ausnutzt, um ein unbeabsichtigtes Verhalten zu erzwingen — etwa Code auszuführen oder Rechte auszuweiten. Er ist das Werkzeug, das aus einer theoretischen Lücke einen praktischen Angriff macht.

    Im Glossar lesen
    kein öffentlicher PoC bekannt
    EPSS-Score

    Der EPSS-Score ist der absolute Modell-Output für eine einzelne Schwachstelle: die geschätzte Wahrscheinlichkeit einer realen Ausnutzung in den nächsten 30 Tagen, ausgedrückt als Wert zwischen 0 und 1 (bzw. 0 % bis 100 %). Ein Score von 0,42 bedeutet „das Modell schätzt eine 42-prozentige Chance auf reale Ausnutzung binnen 30 Tagen“.

    Im Glossar lesen
    0,2 %
    Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
    EPSS-Perzentil

    Das EPSS-Perzentil ist die relative Einordnung einer Schwachstelle innerhalb aller EPSS-bewerteten CVEs, ausgedrückt als Wert zwischen 0 und 1. Ein Perzentil von 0,90 bedeutet „diese CVE hat einen höheren EPSS-Score als 90 % aller anderen bewerteten CVEs“. Anders als der EPSS-Score ist es keine Wahrscheinlichkeit — sondern eine Positionierung im Ranking.

    Im Glossar lesen
    8,9 %
    Niedrig — CVE gehört zu den unteren 10 % der heute bewerteten CVEs.
    KEV-Status

    Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.

    Im Glossar lesen
    —
    Veröffentlicht

    Einordnung nach NIS2 und CRA

    Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

    NIS2

    NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

    Im Glossar lesen
    Behandeln Sie die Schwachstelle im regulären Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2.
    CRA

    Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

    Im Glossar lesen
    Ab dem 11.12.2027 verpflichtet Anhang I Teil II CRA Hersteller betroffener Produkte mit digitalen Elementen, Schwachstellen unverzüglich zu behandeln und Sicherheitsupdates bereitzustellen.
    ISO/IEC 27001

    ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

    Im Glossar lesen
    Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

    Beschreibung

    Im Linux-Kernel wurde folgende Schwachstelle behoben:

    powerpc/entry: Behebung der Speicherbeschädigung von irq_soft_mask bei erneutem Verlassen eines Interrupts

    Wenn __replay_soft_interrupts() einen anstehenden Interrupt (z. B. PACA_IRQ_DEC -> timer_interrupt) erneut ausführt, ruft es den Handler direkt mit einem synthetischen pt_regs auf. Die DEFINE_INTERRUPT_HANDLER_ASYNC-Umgebung jedes Handlers ruft arch_interrupt_async_exit_prepare() auf dem Weg heraus auf, welches arch_interrupt_exit_prepare() -> local_irq_disable() -> arch_local_irq_disable() aufruft, was folgendes tut:

    irq_soft_mask_set(IRQS_DISABLED)   /* 0x1 */

    Dies überschreibt irq_soft_mask unbedingt mit IRQS_DISABLED (0x1) und entfernt den IRQS_PMI_DISABLED (0x2)-Bit. Das Ergebnis ist, dass irq_soft_mask 0x1 anstatt IRQS_ALL_DISABLED (0x3) ist, wenn der Handler zu __replay_soft_interrupts() zurückkehrt.

    Für einen normalen Interrupt ist dies harmlos: der nächste Interrupt tritt immer über arch_interrupt_enter_prepare() ein, welches irq_soft_mask unbedingt auf IRQS_ALL_DISABLED setzt. Während der Wiedergabe wird jedoch next_interrupt() direkt zwischen den wiedergegebenen Handlern aufgerufen, ohne über arch_interrupt_enter_prepare() zurückzukehren, sodass das entfernte Bit nie wiederhergestellt wird. next_interrupt() löst dann eine WARNUNG aus:

    WARNUNG: arch/powerpc/kernel/irq_64.c:75
WARN_ON(irq_soft_mask_return() != IRQS_ALL_DISABLED)

    Die Warnung wurde früh im Bootvorgang auf einem POWER10 pseries-Gast während kmem_cache_init_late() beobachtet, wo das Freigeben eines Spinlocks die Wiedergabe eines Interrupts auslöst, der einen anstehenden Timer-Interrupt verarbeitet.

    Debugger-Zustand, der den Fehler bestätigt: Vor timer_interrupt(&regs): irq_soft_mask = 0x3 (IRQS_ALL_DISABLED) korrekt irq_happened = 0x41 (HARD_DIS|REPLAYING) korrekt Nachdem timer_interrupt(&regs) zurückkehrt: irq_soft_mask = 0x1 (IRQS_DISABLED) FALSCH - PMI-Bit entfernt irq_happened = 0x41 unverändert

    Die Behebung besteht darin, local_irq_disable() durch hard_irq_disable() zu ersetzen.

    hard_irq_disable() ist hier das richtige Primitive aus zwei Gründen:

    1. Auf PPC64 (hw_irq.h:301) ruft es irq_soft_mask_set_return(IRQS_ALL_DISABLED) auf, setzt den Soft-Mask auf 0x3 (sowohl IRQS_DISABLED als auch IRQS_PMI_DISABLED), bewahrt das PMI-Bit und behebt die WARNUNG. Die zusätzliche Arbeit, die es leistet (__hard_irq_disable(), PACA_IRQ_HARD_DIS |=), ist redundant, aber sicher, da beide bereits an diesem Punkt im Ausstiegspfad gesetzt sind; die trace_hardirqs_off() darin ist durch if (!arch_irqs_disabled_flags(flags)) geschützt, sodass sie nicht doppelt ausgelöst wird.

    2. Auf PPC32 (hw_irq.h:467) wird hard_irq_disable() auf arch_local_irq_disable() -> __hard_irq_disable() abgebildet, was MSR[EE] in der Hardware löscht. Dies ist genau richtig: PPC32 hat kein Soft-Mask-PACA-Mechanismus, sodass die Hardware-Deaktivierung die richtige Art ist, die Anforderung von irqentry_exit() zu erfüllen. Dies behebt auch einen Build-Fehler auf PPC32, bei dem irq_soft_mask_set() nur unter CONFIG_PPC64 definiert ist:

      arch/powerpc/include/asm/entry-common.h:273: Fehler: implizite
Deklaration der Funktion 'irq_soft_mask_set'

    Die Verwendung von hard_irq_disable() erfordert kein #ifdef und ist konsistent mit der Art und Weise, wie der Rest des Eintragscodes (z. B. entry-common.h:463) die gleiche PPC32/PPC64-Aufteilung behandelt.

    Quelle: BSI CSAF, BSI WID Portal, cvelistv5, NVD (NIST)

    Quellen & Referenzen

    Re-Analyse & Statuswechsel

    Chronologie der NVD-Audit-Events für diese CVE — Reanalyses, CVSS-Updates, CPE-Diffs.

    1. New CVE Received416baaa9-dc9f-4396-8d5f-8c081fb06d67

      • Description: nachher In the Linux kernel, the following vulnerability has been resolved: powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit When __replay_soft_interrupts() replays a pending interrupt (e.g. PACA_IRQ_DEC -> timer_interrupt), it calls the handler directly with a synthetic pt_regs. The DEFINE_INTERRUPT_HANDLER_ASYNC wrapper around each handler calls arch_interrupt_async_exit_prepare() on the way out, which calls arch_interrupt_exit_prepare() -> local_irq_disable() -> arch_local_irq_disable(), which does: irq_soft_mask_set(IRQS_DISABLED) /* 0x1 */ This unconditionally overwrites irq_soft_mask with IRQS_DISABLED (0x1), stripping the IRQS_PMI_DISABLED (0x2) bit. The result is that irq_soft_mask is 0x1 instead of IRQS_ALL_DISABLED (0x3) when the handler returns to __replay_soft_interrupts(). For a normally-taken interrupt this is harmless: the next interrupt always enters through arch_interrupt_enter_prepare() which unconditionally sets irq_soft_mask to IRQS_ALL_DISABLED. But during replay, next_interrupt() is called directly between replayed handlers without going back through arch_interrupt_enter_prepare(), so the stripped bit is never restored. next_interrupt() then fires a WARNING: WARNING: arch/powerpc/kernel/irq_64.c:75 WARN_ON(irq_soft_mask_return() != IRQS_ALL_DISABLED) The warning was observed early in boot on a POWER10 pseries guest during kmem_cache_init_late(), where a spinlock release triggers interrupt replay that processes a pending timer interrupt. Debugger state confirming the bug: Before timer_interrupt(&regs): irq_soft_mask = 0x3 (IRQS_ALL_DISABLED) correct irq_happened = 0x41 (HARD_DIS|REPLAYING) correct After timer_interrupt(&regs) returns: irq_soft_mask = 0x1 (IRQS_DISABLED) WRONG - PMI bit stripped irq_happened = 0x41 unchanged The fix is to replace local_irq_disable() with hard_irq_disable(). hard_irq_disable() is the right primitive here for two reasons: 1. On PPC64 (hw_irq.h:301) it calls irq_soft_mask_set_return(IRQS_ALL_DISABLED), setting the soft mask to 0x3 (both IRQS_DISABLED and IRQS_PMI_DISABLED), which preserves the PMI bit and fixes the WARNING. The additional work it does (__hard_irq_disable(), PACA_IRQ_HARD_DIS |=) is redundant but safe since both are already set at this point in the exit path; the trace_hardirqs_off() inside is guarded by if (!arch_irqs_disabled_flags(flags)) so it will not double-fire. 2. On PPC32 (hw_irq.h:467) hard_irq_disable() maps to arch_local_irq_disable() -> __hard_irq_disable(), which clears MSR[EE] in hardware. This is exactly correct: PPC32 has no soft-mask PACA mechanism, so the hardware disable is the right way to satisfy irqentry_exit()'s requirement. This also fixes a build error on PPC32 where irq_soft_mask_set() is only defined under CONFIG_PPC64: arch/powerpc/include/asm/entry-common.h:273: error: implicit declaration of function 'irq_soft_mask_set' Using hard_irq_disable() requires no #ifdef and is consistent with how the rest of the entry code (e.g. entry-common.h:463) handles the same PPC32/PPC64 split.
      • Affected: nachher New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/98xxx/CVE-2026-98395.json">CVE-2026-98395</a>
      • Reference: nachher https://git.kernel.org/stable/c/63a7531ca31f9f097d9cc1cc3fe86ae683cdabdd
      • Reference: nachher https://git.kernel.org/stable/c/95cd316a896f1c1aa4ee4a817ba3d4691103c81b