CVE-2026-98068

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılmışdır: net/rds: rds_conn_shutdown() funksiyasının eyni vaxtda baş verən drop əməliyyatını istehlak etməsinə imkan verməyin rds_conn_shutdown() funksiyası yolu RDS_CONN_DISCONNECTING vəziyyətindən RDS_CONN_DOWN vəziyyətinə keçirməklə tamamlanır və həmçinin bu son keçidin başlanğıc vəziyyəti kimi RDS_CONN_ERROR vəziyyətini də qəbul edir ki, sökülmə zamanı softirq kontekstində emal edilən FIN paketi sökülmə prosesini səs-küylü xəta yoluna yönləndirməsin. Lakin həmin RDS_CONN_ERROR vəziyyətinin istehlakı, onunla birlikdə gələn sökülmə mərhələsini də istehlak edir: rds_conn_path_drop() funksiyası RDS_CONN_ERROR vəziyyətini təyin edir və sonra cp_down_w növbəsinə əlavə edir; artıq RDS_CONN_DOWN vəziyyətində olan yolda başlayan mərhələ isə heç bir əməliyyat yerinə yetirmir (no-op). FIN halı üçün bu zərərsizdir - FIN paketinin gəldiyi soket, sökülmənin az öncə azad etdiyi soketin özüdür. Lakin yola əvvəlcədən nəsə bağlayan "dropper" üçün bu zərərlidir. rds_tcp_accept_one() belə bir dropper-dir. Onun rds_tcp_accept_one_path() funksiyasındakı yol iddiası RDS_CONN_DOWN -> RDS_CONN_CONNECTING keçidini həyata keçirir və eyni vaxtda baş verən drop - softirq kontekstində əvvəlki soketdə FIN paketi və ya inzibati sıfırlama - həmin iddia ilə onu qəbul edən vəziyyət yoxlaması arasında yolu RDS_CONN_ERROR vəziyyətinə sala bilər. Daha sonra accept əməliyyatı rds_tcp_set_callbacks() vasitəsilə yeni qəbul edilmiş soketi quraşdırır, halbuki bu soket mövcud olmamışdan əvvəl tc->t_sock-u götürmüş növbədə gözləyən sökülmə prosesi hələ də davam edir. rds_connect_path_complete() funksiyası RDS_CONN_UP vəziyyətinə keçiddə uğursuz olur və yolu yenidən drop edərək, az öncə quraşdırdığı soketi təmizləməli olan mərhələni növbəyə əlavə edir. Əgər davam edən sökülmənin son keçidi həmin drop-un RDS_CONN_ERROR vəziyyətini istehlak edərsə, növbədə gözləyən mərhələ yolu RDS_CONN_DOWN vəziyyətində tapacaq və heç nə etməyəcək. Quraşdırılmış soket heç vaxt sökülmür: o, callback-ləri aktiv şəkildə və rds_tcp_connection-ı rds_tcp_tc_list-də olduğu halda qurulmuş vəziyyətdə qalır, qarşı tərəf heç nə oxunmayan bağlantını görür və yol, daha sonrakı bir hadisə onu yenidən drop edənə qədər RDS_CONN_DOWN vəziyyətində ilişib qalır. Bu, genişləndirilmiş yarış pəncərələri ilə, RDS_CONN_DOWN vəziyyətində ilişib qalmış yolun sahibliyi altında olan soketdə daim böyüyən qəbul növbəsi və qarşı tərəfin göndərmə yolunun onun arxasında ilişməsi şəklində təkrar istehsal edilmişdir. Son keçidi yalnız DISCONNECTING -> DOWN olaraq təyin edin. Əgər yol RDS_CONN_ERROR vəziyyətində olduğu üçün bu uğursuz olarsa, deməli drop əməliyyatı sökülmə ilə yarışmışdır: yenidən qoşulma taymerini ləğv edin və RDS_RECONNECT_PENDING vəziyyətini təmizləyin - ötürülmüş son hissənin geridə qalmaması gərəkən yeganə hissəsi budur - və geri dönün, beləliklə drop-un növbəyə əlavə etdiyi mərhələ işi tamamlasın: o, həmin müddət ərzində yola bağlanmış hər şeyi sökür, RDS_CONN_DOWN vəziyyətinə keçidi tamamlayır və yenidən qoşulmanı öz sonundan aktivləşdirir. Həmin budaqdakı taymerin sakitləşdirilməsi vacibdir, çünki yarışan drop həmişə həmin mərhələni növbəyə əlavə etmir: rds_conn_path_drop() funksiyası destroy gözləniləndə növbəyə əlavə etmədən geri dönür - bu, netns sökülməsi və ya modulun yüklənməməsi zamanı, rds_conn_path_destroy() cp_down_w-nu boşaldarkən ölməkdə olan soketdə FIN paketi emal edildikdə baş verən vəziyyətdir. Əgər boşaldılan mərhələ bu geri dönüşü edən mərhələdirsə, daha sonrakı mərhələ mövcud olmayacaq və rds_conn_path_destroy() cp_conn_w-nun hələ də aktiv olduğunu görəcək (WARN_ON) və sonra yenidən qoşulma taymeri hələ də işləyə bilən yolu azad edəcək. Budaqdakı ləğv etmə ilə, hansı mərhələ keçidi tamamlamasından asılı olmayaraq, sökülmə mərhələsinin hər bir çıxışı taymeri sakitləşdirilmiş vəziyyətdə saxlayır. FIN halı, bir mərhələ sonra və hələ də səs-küylü loqlama olmadan irəliləməyə davam edir. Hər hansı digər vəziyyət bugünkü rds_conn_path_error() emalını saxlayır; hazırkı heç bir cp_state yazıcısı DISCONNECTING yolunu RDS_CONN_ERROR-dan başqa heç bir vəziyyətdə qoya bilməz (digər bütün yazıcılar qeyri-DISCONNECTING vəziyyətdən cmpxchg edirlər), buna görə də həmin budaq preventiv xarakter daşıyır. Əvvəlki yamalar tətbiq olunmamış nüvələrdə nümunə əsaslı sakitləşdirmə ilə eyni risk mövcuddur; düzəliş orada da eynilə tətbiq olunur.