Mittel28 / 100Konfidenz: Mittel

CVSS9.8EPSS0.8 %Über Netz erreichbarOhne AnmeldungOhne Zutun des Nutzers

Installieren Sie umgehend die von Red Hat bereitgestellten Sicherheitsupdates.

▸Herleitung der Bewertung(2)

Wie der Wert zustande kommt

Hoechster CVSS-Basiswert 9.8+18
Ohne Anmeldung ueber das Netz ausnutzbar (CVE-2025-71132, CVSS-Vektor AV:N/PR:N)+10

Woraus sich die Konfidenz ergibt

Nur ein Herausgeber — keine Gegenlesung
Strukturierte CVE-Daten aus der NVD vorhanden

Die Konfidenz misst die Belegqualität, nicht die Schwere.

Einschränkungen

Schmale Datenlage: der Wert beruht auf wenigen Einzelsignalen.
2 im Text genannte CVE(s) liegen uns nicht vor und gehen nicht in die Bewertung ein: CVE-2025-21834, CVE-2026-43454
Fuer 3 erkannte CVE(s) liegt noch kein CVSS-Basiswert vor (NVD-Rueckstau).

Bewertung v1.2, deterministisch berechnet. Bedrohungswert und Konfidenz sind getrennte Größen.· 2026-09-04 00:00 UTCMethodik

Multiples vulnérabilités dans le noyau Linux de Red Hat (04 septembre 2026)

CERT-FR·4. September 2026, 00:00

Originalartikel lesen bei CERT-FR

Mehrere kritische Schwachstellen wurden im Red Hat Linux-Kernel entdeckt, die zu Datenintegritätsverletzungen, Offenlegung vertraulicher Informationen und der Ausführung von beliebigem Code führen können. Betroffen sind zahlreiche Red Hat CodeReady Linux Builder-Produkte auf verschiedenen Architekturen. Es wird dringend empfohlen, die von Red Hat bereitgestellten Sicherheitsupdates umgehend zu installieren, um diese Risiken zu mindern.

SecBoard-Einordnung

Organisationen, die Red Hat CodeReady Linux Builder einsetzen, sind einem hohen Risiko ausgesetzt, da die Schwachstellen die Integrität von Daten, die Vertraulichkeit von Informationen und die Systemkontrolle beeinträchtigen können.

Realistisch schlimmster Fall: Ein Angreifer könnte beliebigen Code auf betroffenen Systemen ausführen, was zu einem vollständigen Kompromittierung des Systems und potenziell zu weitreichenden Datenverlusten oder -manipulationen führen könnte.

Im erfassten Bestand

▸CVE-2026-23003 kommt damit in 4 erfassten Meldungen der letzten 90 Tage vor.

Gezählt im eigenen Bestand, rückwärts ab dem Erscheinungsdatum. Das ist Belegstärke, keine Aussage über die Häufigkeit in der Welt.

Key Facts· 12 / 57

Nach Dringlichkeit sortiert: KEV-Eintrag, dann CVSS, dann EPSS. Vollstaendige Liste im Meldungstext.

CVE-2026-72130

CVSS: 9.8 · CRITICAL
EPSS: 0.8%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-72069

CVSS: 9.8 · CRITICAL
EPSS: 0.7%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-64268

CVSS: 9.8 · CRITICAL
EPSS: 0.7%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-53399

CVSS: 9.8 · CRITICAL
EPSS: 0.7%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-63800

CVSS: 9.8 · CRITICAL
EPSS: 0.6%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-74480

CVSS: 9.8 · CRITICAL
EPSS: 0.6%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-64384

CVSS: 9.8 · CRITICAL
EPSS: 0.5%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-74581

CVSS: 9.8 · CRITICAL
EPSS: 0.4%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-64136

CVSS: 9.8 · CRITICAL
EPSS: 0.4%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-53006

CVSS: 9.8 · CRITICAL
EPSS: 0.4%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-43114

CVSS: 9.4 · CRITICAL
EPSS: 0.4%
Über das Netz: ja
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2026-64018

CVSS: 9.3 · CRITICAL
EPSS: 0.1%
Über das Netz: nein
Anmeldung nötig: nein
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

Betroffen

Zahlreiche Red Hat CodeReady Linux Builder-Produkte auf verschiedenen Architekturen sind betroffen.

Hersteller

LinuxRedhat

Produkte

Enterprise Linux3 VersionenLinux Kernel4 Versionen

▸ CPE-Rohbezeichner anzeigen (25)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.11:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.11:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.11:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.11:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.11:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.8:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:*
cpe:2.3:o:redhat:enterprise_linux:10.0:*:*:*:*:*:*:*
cpe:2.3:o:redhat:enterprise_linux:8.0:*:*:*:*:*:*:*
cpe:2.3:o:redhat:enterprise_linux:9.0:*:*:*:*:*:*:*

Prüfen

▸Überprüfen Sie, ob Red Hat CodeReady Linux Builder-Produkte in Ihrer Umgebung eingesetzt werden.
▸Verifizieren Sie, dass alle Red Hat CodeReady Linux Builder-Installationen auf die neuesten, von Red Hat bereitgestellten Sicherheitsupdates aktualisiert wurden.

▸ 1 weitere

▸Scannen Sie Ihre Systeme auf bekannte Schwachstellen im Linux-Kernel, insbesondere solche, die Red Hat betreffen.

Offene Punkte

▸ anzeigen

▸Spezifische CVE-Nummern der Schwachstellen sind nicht im Artikel genannt.
▸Details zu den genauen Versionen von Red Hat CodeReady Linux Builder, die betroffen sind, sind nicht im Artikel aufgeführt.
▸Die genaue Art der 'verschiedenen Architekturen' wird nicht spezifiziert.

Red-Team-Relevanz

Was heißt das für dein nächstes Assessment?

▸ Einordnung anzeigen

Initial Access möglich?Unklar
Privilege Escalation relevant?Unklar
Exploit öffentlich verfügbar?Möglich
Detection / Logging prüfbar?Möglich
Für Purple-Team-Szenario geeignet?Unklar

Kundenfragen

Haben wir SAP extern erreichbar?

MITRE ATT&CK(3)

Techniken aus allen Quellen zusammengeführt — nach Stärke des Belegs sortiert.

T1059Command and Scripting Interpreterzugeordnet

„Ausführung von beliebigem Code“

T1490Inhibit System Recoveryzugeordnet

„Datenintegritätsverletzungen“

T1560Archive Collected Datazugeordnet

„Offenlegung vertraulicher Informationen“

Mehrere Herkünfte bei derselben Technik heißt: mehrere unabhängige Wege führen dorthin.

Quellen & Belege· 1 Quelle

CERT-FRKontextUNKNOWNdiese Meldung

Quelle nicht eingeordnet.

Nur eine Quelle — der Sachverhalt ist an keiner zweiten Stelle gegengelesen.
Mindestens eine Quelle ist noch nicht nach Herkunftsklasse eingeordnet.

Verknüpfte Intelligence

Dieselben Entitäten an anderer Stelle auf SecBoard.

Vollständigen Artikel lesen bei CERT-FR

Erwähnte CVEs (12)

CVE-2026-72130CRITICAL(9.8)

EPSS 0.8%

In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.

Details NVD

CVE-2026-72069CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1 T2 spin_lock(&p->lock); rcu_read_lock(); invalidate(p); p = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL); if (!p) return; spin_unlock(&p->lock); spin_lock(&p->lock) lock(&lock->lock); rcu_read_lock(); kfree_rcu(p); rcu_read_unlock(); .... spin_unlock(&p->lock) rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); UAF -> rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.

Details NVD

CVE-2026-64268CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.

Details NVD

CVE-2026-53399CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: nfsd: release layout stid on setlease failure nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).

Details NVD

CVE-2026-63800CRITICAL(9.8)

EPSS 0.6%

In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).

Details NVD

CVE-2026-74480CRITICAL(9.8)

EPSS 0.6%

In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.

Details NVD

CVE-2026-64384CRITICAL(9.8)

EPSS 0.5%

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix change notify replay double-free A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_notify_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free.

Details NVD

CVE-2026-74581CRITICAL(9.8)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: net: ipv6: clear suppressed fib6 rule result fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(), but leaves res->rt6 pointing at the released rt6_info. If no later rule supplies a replacement, fib6_rule_lookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6_lookup(), and the next put hits rcuref_put_slowpath() from dst_release(). Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one.

Details NVD

CVE-2026-64136CRITICAL(9.8)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: smb: client: protect tc_count increment in smb2_find_smb_sess_tcon_unlocked() Commit 96c4af418586 ("cifs: Fix locking usage for tcon fields") refactored cifs code to change cifs_tcp_ses_lock for tc_lock around tc_count changes. There was missing lock around tc_count increment inside smb2_find_smb_sess_tcon_unlocked().

Details NVD

CVE-2026-53006CRITICAL(9.8)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in icmpv6_rcv() Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call.

Details NVD

CVE-2026-43114CRITICAL(9.4)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted "a . b", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.

Details NVD

CVE-2026-64018CRITICAL(9.3)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: net: mana: validate rx_req_idx to prevent out-of-bounds array access In mana_hwc_rx_event_handler(), rx_req_idx is derived from sge->address in DMA-coherent memory. In Confidential VMs (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify WQE contents at any time. No bounds check exists on rx_req_idx, which can lead to an out-of-bounds access into reqs[]. Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before using it to index the reqs[] array.

Details NVD