CVE-2026-64025

Linux kernel-də aşağıdakı zəiflik aradan qaldırılmışdır: bpf, skmsg: sk_data_ready hökmünün ktls rx ilə yarış vəziyyətinin (race condition) düzəldilməsi sk_psock_strp_data_ready() artıq tls_sw_has_ctx_rx()-i yoxlayır və TLS RX konteksti mövcud olduqda psock->saved_data_ready funksiyasına yönəlir ki, bu da TLS strparser-in qəbul növbəsinə sahibliyi ilə münaqişənin qarşısını alır (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls"). sk_psock_verdict_data_ready() funksiyasında buna bənzər bir qoruyucu mexanizm yoxdur. Soket TLS RX konfiqurasiya edilməmişdən əvvəl sockmap-ə (BPF_SK_SKB_VERDICT) daxil edildikdə, tls_sw_strparser_arm() funksiyası sk_psock_verdict_data_ready-ni rx_ctx->saved_data_ready kimi saxlayır. Məlumat gəldikdə: tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready -> saved_data_ready() = sk_psock_verdict_data_ready() -> tcp_read_skb() tcp_eat_skb() çağırılmadan __skb_unlink() vasitəsilə sk_receive_queue-nu boşaldır, buna görə də copied_seq artmır. Daha sonra tls_strp_msg_load() tcp_inq() >= full_len (köhnəlmiş) olduğunu aşkar edir, artıq boş olan növbədə tcp_recv_skb()-ni çağırır, WARN_ON_ONCE(!first) xətasına rast gəlir və rx_ctx->strp.anchor.frag_list psock-a məxsus (potensial olaraq azad edilmiş) skb-yə işarə etdikdə geri dönür. Nəticədə tls_decrypt_sg() həmin frag_list üzrə keçid edir: use-after-free. sk_psock_strp_data_ready() ilə eyni düzəlişi tətbiq edin: əgər TLS RX konteksti mövcuddursa, recv() gözləyənlərini oyatmaq üçün psock->saved_data_ready (sock_def_readable) çağırılsın və qəbul növbəsinə toxunmadan dərhal geri dönülsün. TLS növbənin yeganə sahibi olaraq qalır və qeydi normal şəkildə tls_sw_recvmsg() vasitəsilə dekripsiya edir.