CVE-2026-64025

Linux kernel (GCP) vulnerabilities

Beschreibung

Im Linux-Kernel wurde die folgende Schwachstelle behoben: bpf, skmsg: Behebung des Rennzustands von verdict sk_data_ready mit ktls rx sk_psock_strp_data_ready() überprüft bereits tls_sw_has_ctx_rx() und wechselt zu psock->saved_data_ready, wenn ein TLS RX-Kontext vorhanden ist, um einen Konflikt mit dem Besitz des Empfangsqueues durch den TLS-Parser zu vermeiden (Commit e91de6afa81c, "bpf: Behebung der Ausführung von sk_skb Programmtypen mit ktls"). sk_psock_verdict_data_ready() hat keinen vergleichbaren Schutz. Wenn ein Socket in eine sockmap (BPF_SK_SKB_VERDICT) eingefügt wird, bevor TLS RX konfiguriert ist, speichert tls_sw_strparser_arm() sk_psock_verdict_data_ready als rx_ctx->saved_data_ready. Bei Eintreffen von Daten: tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready() = sk_psock_verdict_data_ready() -> tcp_read_skb() entleert sk_receive_queue über __skb_unlink() ohne tcp_eat_skb() aufzurufen, sodass copied_seq nicht fortgeschritten wird. tls_strp_msg_load() findet dann tcp_inq() >= full_len (veraltet), ruft tcp_recv_skb() auf dem nun leeren Queue auf, stößt auf WARN_ON_ONCE(!first) und gibt zurück mit rx_ctx->strp.anchor.frag_list, das auf ein psock-eigenes (potenziell freigegebenes) skb zeigt. tls_decrypt_sg() durchläuft anschließend diese frag_list: Verwendung nach Freigabe. Wenden Sie den gleichen Fix wie bei sk_psock_strp_data_ready an: Wenn ein TLS RX-Kontext vorhanden ist, rufen Sie psock->saved_data_ready (sock_def_readable) auf, um die recv()-Wartenden zu wecken und sofort zurückzukehren, ohne das Empfangsqueue zu berühren. TLS behält alleinigen Besitz des Queues und entschlüsselt den Datensatz normalerweise über tls_sw_recvmsg().

Quelle: UBUNTU_USN BSI BSI_CSAF UBUNTU_USN UBUNTU_USN UBUNTU_USN UBUNTU_USN UBUNTU_USN UBUNTU_USN CVELISTV5 NVD CVEORG