Hoch53 / 100Konfidenz: Mittel

In CISA KEVCVSS9.8EPSS1 %Ohne Zutun des Nutzers

▸Herleitung der Bewertung(3)

Wie der Wert zustande kommt

Im CISA-KEV-Katalog: CVE-2025-39964, CVE-2026-53266+25
Hoechster CVSS-Basiswert 9.8+18
Ohne Anmeldung ueber das Netz ausnutzbar (CVE-2026-31539, 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

2 im Text genannte CVE(s) liegen uns nicht vor und gehen nicht in die Bewertung ein: CVE-2026-23007, CVE-2026-31692
Fuer 4 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-02 00:00 UTCMethodik

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

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

Originalartikel lesen bei CERT-FR

Mehrere Schwachstellen wurden im Linux-Kernel von Red Hat entdeckt, die zu Datenintegritäts- und Vertraulichkeitsverletzungen, Umgehung von Sicherheitsrichtlinien, Denial-of-Service, Remote-Code-Ausführung und Privilegienerhöhung führen können. Betroffen sind verschiedene Red Hat CodeReady Linux Builder Versionen für ARM 64. Nutzern wird dringend empfohlen, die entsprechenden Sicherheitsupdates von Red Hat zu installieren.

SecBoard-Einordnung

Diese Schwachstellen können zu schwerwiegenden Sicherheitsverletzungen führen, einschließlich der Ausführung von Remote-Code und der Erlangung erhöhter Privilegien, was die vollständige Kompromittierung betroffener Systeme ermöglicht.

Realistisch schlimmster Fall: Der schlimmste Fall ist die vollständige Kompromittierung von Systemen durch Remote-Code-Ausführung und Privilegienerhöhung, was zu Datenverlust, Datenmanipulation und Betriebsunterbrechungen führen kann.

Empfehlung: Installieren Sie umgehend die von Red Hat bereitgestellten Sicherheitsupdates für alle betroffenen Red Hat CodeReady Linux Builder für ARM 64 Extended Update Support Versionen.

Im erfassten Bestand

▸CVE-2025-39964 kommt damit in 7 erfassten Meldungen der letzten 90 Tage vor.
▸CVE-2025-39964 stand zum Zeitpunkt dieser Meldung seit 7 Tagen im KEV-Katalog der CISA.

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 / 81

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

CVE-2026-53266CISA KEV

CVSS: 8.8 · HIGH
EPSS: 0.8%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
im KEV seit: 2026-09-18
Patch: unbekannt

CVE-2025-39964CISA KEV

CVSS: 7.8 · HIGH
EPSS: 1.4%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
im KEV seit: 2026-09-18
Patch: unbekannt

CVE-2026-64564

CVSS: 9.8 · CRITICAL
EPSS: 1.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-63887

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

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

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

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

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

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

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

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

Betroffen

Nutzer von verschiedenen Red Hat CodeReady Linux Builder Versionen für ARM 64 Extended Update Support sind betroffen.

Hersteller

LinuxRedhatSiemens

Produkte

KernelEnterprise Linux4 VersionenLinux Kernel3 VersionenSimatic S7 1500 Cpu 1518 4 PN\/DP MFP FirmwareSimatic S7 1500 Cpu 1518F 4 PN\/DP MFP Firmware

▸ CPE-Rohbezeichner anzeigen (26)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc6:*:*:*:*:*:*
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.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:*:*:*:*:*:*
cpe:2.3:o:redhat:enterprise_linux:10.0:*:*:*:*:*:*:*
cpe:2.3:o:redhat:enterprise_linux:7.0:*:*:*:*:*:*:*
cpe:2.3:o:redhat:enterprise_linux:8.0:*:*:*:*:*:*:*
cpe:2.3:o:redhat:enterprise_linux:9.0:*:*:*:*:*:*:*
cpe:2.3:o:siemens:simatic_s7-1500_cpu_1518-4_pn\/dp_mfp_firmware:*:*:*:*:*:*:*:*
cpe:2.3:o:siemens:simatic_s7-1500_cpu_1518f-4_pn\/dp_mfp_firmware:*:*:*:*:*:*:*:*

Prüfen

▸Überprüfen Sie, ob Ihre Systeme Red Hat CodeReady Linux Builder für ARM 64 Extended Update Support Versionen verwenden.
▸Stellen Sie sicher, dass alle Red Hat-Systeme die neuesten Sicherheitsupdates für den Linux-Kernel installiert haben.

▸ 1 weitere

▸Scannen Sie Ihre Systeme auf bekannte Schwachstellen im Linux-Kernel, insbesondere auf die in diesem Bericht genannten.

Offene Punkte

▸ anzeigen

▸Die spezifischen CVE-IDs der Schwachstellen sind nicht angegeben.
▸Die genauen Versionen von Red Hat CodeReady Linux Builder für ARM 64, die betroffen sind, sind nicht detailliert.
▸Es wird nicht angegeben, ob die Schwachstellen aktiv ausgenutzt werden.

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?Ja
Detection / Logging prüfbar?Möglich
Für Purple-Team-Szenario geeignet?Unklar

Kundenfragen

Haben wir SAP extern erreichbar?

MITRE ATT&CK(4)

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

T1059Command and Scripting Interpreterzugeordnet

„Remote-Code-Ausführung“

T1068Exploitation for Privilege Escalationzugeordnet

„Privilegienerhöhung“

T1499Denial of Servicezugeordnet

„Denial-of-Service“

T1562Impair Defenseszugeordnet

„Umgehung von Sicherheitsrichtlinien“

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-53266HIGH(8.8)

KEVEPSS 0.8%

In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().

Details NVD

CVE-2025-39964HIGH(7.8)

KEVEPSS 1.4%

In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.

Details NVD

CVE-2026-64564CRITICAL(9.8)

EPSS 1.4%

In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.

Details NVD

CVE-2026-63887CRITICAL(9.8)

EPSS 0.8%

In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates "key=value\0" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: *length += sprintf(output_buf, "%s=%s", er->key, er->value); *length += 1; output_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)

Details NVD

CVE-2026-63888CRITICAL(9.8)

EPSS 0.8%

In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.

Details NVD

CVE-2026-68159CRITICAL(9.8)

EPSS 0.7%

In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]

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

EPSS 0.5%

In the Linux kernel, the following vulnerability has been resolved: ipvs: do not propagate one-packet flag to synced conns Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags. IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn. Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections.

Details NVD

CVE-2026-64383CRITICAL(9.8)

EPSS 0.5%

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double-free in SMB2_flush() replay SMB2_flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifs_send_recv() stores a replacement response, flush_exit will free the stale response pointer a second time. Reinitialize resp_buftype and rsp_iov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.

Details NVD

CVE-2026-52993CRITICAL(9.8)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations.

Details NVD

CVE-2026-74569CRITICAL(9.8)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and "datalen = datalen + diff - msglen" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...

Details NVD

CVE-2026-53002CRITICAL(9.8)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: remove sprintf usage Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check. Increase buffer size in mangle_content_len() while at it. BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270 Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..]

Details NVD