CVE-2026-23450

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: net/smc: smc_tcp_syn_recv_sock() funksiyasında NULL dereference və UAF xətası düzəldildi Syzkaller smc_tcp_syn_recv_sock() funksiyasında panika hesabatı vermişdir [1]. smc_tcp_syn_recv_sock() funksiyası TCP qəbul yolunda (softirq), clcsock (TCP dinləmə soketi) üzərində icsk_af_ops->syn_recv_sock vasitəsilə çağırılır. O, smc_sock göstəricisini əldə etmək üçün sk_user_data dəyərini oxuyur. Lakin, SMC dinləmə soketi eyni vaxtda bağlanarkən, smc_close_active() funksiyası sk_callback_lock altında clcsock->sk_user_data dəyərini NULL təyin edir və daha sonra smc_sock özü smc_release() daxilində sock_put() vasitəsilə azad edilə bilər. Bu, iki problemə səbəb olur: 1) NULL pointer dereference: giriş zamanı sk_user_data NULL olur. 2) Use-after-free: sk_user_data NULL olmayan kimi oxunur, lakin onun sahələrinə (məsələn, queued_smc_hs, ori_af_ops) daxil olmazdan əvvəl smc_sock azad edilir. Yarış pəncərəsi belə görünür (syzkaller çökməsi [1] SYN cookie yolu vasitəsilə tetiklenir: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), lakin normal tcp_check_req() yolu da eyni yarışa malikdir): CPU A (softirq) CPU B (proses ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* Dinləyici üzərində kilid yoxdur */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock azad edildi! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL və ya asılı (dangling) smc->queued_smc_hs -> çökdü! Qeyd edin ki, clcsock və smc_sock ayrı refcount-lara malik iki müstəqil obyektdir. TCP steki clcsock üzərində istinad saxlayaraq onu aktiv tutur, lakin bu, smc_sock-un azad edilməsinə mane OLMUR. smc_sock obyektinə təhlükəsiz daxil olmaq üçün RCU və refcount_inc_not_zero() istifadə etməklə bu problemi həll edin. smc_tcp_syn_recv_sock() funksiyası TCP üçtərəfli əl sıxma (three-way handshake) yolunda çağırıldığı üçün, sk_callback_lock üzərində read_lock_bh götürmək çox ağır prosesdir və SYN flood hücumuna davam gətirə bilməzdi. rcu_read_lock() istifadə etmək daha yüngül variantdır. - SMC dinləmə soketində SOCK_RCU_FREE təyin edin ki, smc_sock-un azad edilməsi RCU grace dövründən sonraya təxirə salınsın. Bu, rcu_read_lock() daxilində daxil olduqda yaddaşın hələ də etibarlı olduğunu təmin edir. - sk_user_data oxunuşunu qorumaq üçün rcu_read_lock() istifadə edin. - smc_sock-u sabitləmək üçün refcount_inc_not_zero(&smc->sk.sk_refcnt) istifadə edin. Əgər refcount artıq sıfıra çatmışsa (bağlanma yolu tamamlanıbsa), o, false qaytarır və biz təhlükəsiz şəkildə çıxırıq. Qeyd: smc_hs_congested() funksiyasının da rcu_read_lock() olmadan sk_user_data-nın oxşanarına bənzər kilidsiz oxuması var, lakin o yalnız NULL-u yoxlayır və qlobal smc_hs_wq-ya müraciət edir, heç bir smc_sock sahəsini dereference etmir, buna görə də təsirlənmir. Reproducer mdelay injeksiya və smc_run ilə təsdiqlənmişdir, bu yam tətbiq edildikdən sonra problem artıq baş vermir. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9