CVE-2024-57974

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılmışdır: udp: UDP soket ünvanının dəyişdirilməsi və yenidən heşlənməsi (rehash) arasındakı yarış vəziyyətinin (race condition) həlli Əgər bir UDP soketi dataqramları qəbul etdiyi zaman connect() nəticəsində öz lokal ünvanını dəyişirsə, ünvan dəyişdirildikdən sonra, lakin ikincili heş (port və ünvan) və dördlü heş (lokal və uzaq portlar və ünvanlar) yenilənmədən əvvəl belə bir dövr yaranır ki, bu müddətdə axtarış əməliyyatı onu tapa bilməyə bilər. İkincili heş zəncirləri 30fff9231fad ("udp: bind() optimisation") komiti ilə tətbiq edilmişdir və bunun nəticəsində connect()-dən sonra bağlanmış (bound) soketin yenidən əlçatan olması üçün yenidən heşləmə (rehash) əməliyyətinə ehtiyac yaranmışdır. Bu əməliyyat 719f835853a9 ("udp: add rehash on connect()") komiti ilə tətbiq edilmişdir, lakin bu tam həll yolu deyil: yenidən heşləmə tamamlandıqda soket tapılacaq, lakin proses davam edərkən tapılmayacaq. Bu hal UDP4-LISTEN rejimində olan socat(1) serveri və ona dataqramlar göndərən klient ilə müşahidə olunur. Server ilk dataqramı qəbul etdikdən sonra (bax: _xioopen_ipdgram_listen()), yönləndirilmiş axın qurmaq üçün göndərənin ünvanına connect() çağırışı edir. İndi, fərqli CPU axınında işləyən klient, serverin soketi ünvanını dəyişdirdiyi, lakin hələ yenidən heşlənmədiyi anda (növbəti) dataqram göndərsə, bu, uğursuz axtarışla və klientə çatdırılan "port unreachable" xətası ilə nəticələnəcək, bu da aşağıdakı reproduksiyada görünür: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait done burada klient sonda write() zamanı ECONNREFUSED alacaq (adətən verilmiş iterasiyanın ikinci və ya üçüncü yazma əməliyyatında): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused Bu problem ilk dəfə kontenerin şəbəkə ad sahəsini (network namespace) bağlamaq üçün pasta(1) istifadə edərkən UDP funksionallığını yoxlayan Podman testlərində nadir hallarda baş verən xəta kimi müşahidə edilmişdir. Bu bizi axtarış xətasının tap cihazında ICMP paketi ilə nəticələndiyi reproduksiyaya gətirdi: LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done Xəta baş verdikdə: tmp.in tmp.out differ: char 8193, line 29 nəyin baş verdiyinə baxa bilərik: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0 Üçüncü dataqram qəbul edildikdə, kontenerin şəbəkə ad sahəsi ICMP mesajını çatdırmaq üçün ARP axtarışı başladır. Bu reproduksiyanın digər variantında, klienti aşağıdakı şəkildə başlatdıqda: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru ---kəsilmiş---