Mittel28 / 100Konfidenz: Mittel

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

Installieren Sie umgehend alle von Red Hat bereitgestellten Sicherheitsupdates für die betroffenen Linux-Kernel-Versionen.

▸Herleitung der Bewertung(2)

Wie der Wert zustande kommt

Hoechster CVSS-Basiswert 10.0+18
Ohne Anmeldung ueber das Netz ausnutzbar (CVE-2022-49670, 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.
1 im Text genannte CVE(s) liegen uns nicht vor und gehen nicht in die Bewertung ein: CVE-2026-31581
Fuer 5 erkannte CVE(s) liegt noch kein CVSS-Basiswert vor (NVD-Rueckstau).

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

Multiples vulnérabilités dans le noyau Linux de Red Hat (09 octobre 2026)

CERT-FR·9. Oktober 2026, 00:00

Originalartikel lesen bei CERT-FR

Es wurden mehrere kritische Schwachstellen im Linux-Kernel von Red Hat entdeckt, die eine Vielzahl von Red Hat CodeReady Linux Builder-Produkten betreffen. Diese Lücken ermöglichen unter anderem die Ausführung von beliebigem Code, Datenmanipulation und Denial-of-Service-Angriffe. Betroffene Nutzer sollten umgehend die von Red Hat bereitgestellten Sicherheitsupdates installieren, um ihre Systeme zu schützen.

SecBoard-Einordnung

Diese Schwachstellen können zu schwerwiegenden Sicherheitsverletzungen führen, einschließlich der vollständigen Kompromittierung von Systemen und der Manipulation oder Offenlegung sensibler Daten.

Realistisch schlimmster Fall: Ein Angreifer könnte beliebigen Code mit erhöhten Privilegien ausführen, Daten manipulieren oder löschen und Systeme unzugänglich machen, was zu Betriebsunterbrechungen und Datenverlust führen kann.

Im erfassten Bestand

▸CVE-2026-53185 kommt damit in 7 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 / 99

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

CVE-2026-74705

CVSS: 10.0 · 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-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-72098

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-63922

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-63924

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-72129

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-89972

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-89669

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-43493

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-52924

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-72317

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-53398

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

Betroffen

Organisationen, die Red Hat CodeReady Linux Builder-Produkte auf verschiedenen Architekturen (ARM 64, IBM z Systems, Power little endian, x86_64) verwenden, sind betroffen.

Hersteller

Linux

Produkte

Linux Kernel2 Versionen

▸ CPE-Rohbezeichner anzeigen (12)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:2.6.12: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:linux:linux_kernel:7.1:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc6:*:*:*:*:*:*

Prüfen

▸Überprüfen Sie, ob Red Hat CodeReady Linux Builder-Produkte in Ihrer Umgebung eingesetzt werden.
▸Stellen Sie sicher, dass alle Red Hat Linux-Systeme auf die neuesten Kernel-Versionen gepatcht sind.

▸ 1 weitere

▸Überwachen Sie Systemprotokolle auf ungewöhnliche Aktivitäten oder Anzeichen von Kompromittierung nach der Patch-Installation.

Offene Punkte

▸ anzeigen

▸Spezifische CVE-IDs der Schwachstellen sind im Artikel nicht genannt.
▸Details zu den Angriffsvektoren sind nicht spezifiziert.
▸Informationen über bereits erfolgte Ausnutzung der Schwachstellen sind nicht verfügbar.

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(5)

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

T1059Command and Scripting Interpreterzugeordnet

„Ausführung von beliebigem Code“

T1068Exploitation for Privilege Escalationzugeordnet

„privilege escalation“

T1485Data Destructionzugeordnet

„Datenmanipulation“

T1499Denial of Servicezugeordnet

„Denial-of-Service-Angriffe“

T1530Data from Cloud Storagezugeordnet

„data integrity and confidentiality breaches“

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-74705CRITICAL(10.0)

EPSS 0.5%

In the Linux kernel, the following vulnerability has been resolved: udp: fix potential use-after-free in tunnel segmentation __skb_udp_tunnel_segment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid. Get the UDP header after the pull to avoid a potential use-after-free.

Details NVD

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-72098CRITICAL(9.8)

EPSS 0.8%

In the Linux kernel, the following vulnerability has been resolved: dm-verity: fix buffer overflow in FEC calculation There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) fio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.

Details NVD

CVE-2026-63922CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.

Details NVD

CVE-2026-63924CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.

Details NVD

CVE-2026-72129CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: sg->offset = off; sg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).

Details NVD

CVE-2026-89972CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: nvme: add missing SRCU grace period in error path nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path.

Details NVD

CVE-2026-89669CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.

Details NVD

CVE-2026-43493CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.

Details NVD

CVE-2026-52924CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.

Details NVD

CVE-2026-72317CRITICAL(9.8)

EPSS 0.6%

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: pin upper rpc_clnt across the TLS connect_worker The TLS connect path has a use-after-free: nothing pins the upper rpc_clnt across the delayed connect_worker. xs_connect() stores task->tk_client in sock_xprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xs_tcp_tls_setup_socket(), which reads several fields out of the saved pointer (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) to construct the args for the inner handshake rpc_clnt. The xprt does not reference the rpc_clnt; the rpc_clnt references the xprt. xs_destroy() does cancel the connect_worker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpc_clnt releases its cl_xprt reference in rpc_free_client_work(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpc_shutdown_client(), and the upper rpc_clnt is freed before the queued connect_worker fires. xs_tcp_tls_setup_socket() then dereferences the freed clnt, producing the refcount_t underflow Michael Nemanov reported. Take a reference on the upper rpc_clnt in xs_connect() for TLS transports via a new rpc_hold_client() helper, and drop it in the connect_worker's exit path with rpc_release_client(). The xprt_lock_connect() / xprt_unlock_connect() pairing already serialises xs_connect() with xs_tcp_tls_setup_socket(), so the take and release are balanced one-for-one. The non-TLS connect worker (xs_tcp_setup_socket) never reads sock_xprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.

Details NVD

CVE-2026-53398CRITICAL(9.8)

EPSS 0.5%

In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 ("NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().

Details NVD