CVE-2026-42959

W NLnet Labs Unbound do wersji 1.26.0 włącznie znaleziono podatność w walidatorze DNSSEC, która umożliwia atak DoS i potencjalne zdalne wykonanie kodu przez przetwarzanie DNSKEY. Specjalnie spreparowany DNSKEY z wskaźnikiem kompresji właściciela może przepełnić bufor.

W bibliotece Unbound od wersji 1.4.22 do 1.25.1 stwierdzono podatność na zatruwanie pamięci podręcznej DNS. Problem wynika z deterministycznego przypisywania zakresów portów UDP do wątków roboczych przy włączonej opcji SO_REUSEPORT, co umożliwia atakującemu przewidzenie portu źródłowego i obniżenie entropii transakcji DNS.

NLnet Labs Unbound do wersji 1.25.0 włącznie jest podatny na zatruwanie pamięci podręcznej poprzez promiscuous rekordy w sekcji autorytatywnej. Atakujący może wstrzyknąć rekordy inne niż NS (np. MX) wraz z rekordami adresowymi, które Unbound buforuje, co prowadzi do zatrucia pamięci podręcznej. Wersja 1.25.1 zawiera poprawkę odrzucającą rekordy adresowe z sekcji dodatkowej, jeśli nie są one jawnie związane z rekordami NS.

NLnet Labs Unbound od wersji 1.19.1 do 1.25.0 ma podatność w walidatorze DNSSEC polegającą na błędzie przypisania struktury podczas głębokiego kopiowania, co prowadzi do wiszącego wskaźnika i potencjalnego wykonania kodu.

NLnet Labs Unbound w wersjach od 1.22.0 do 1.26.1 zawiera błąd cyklu życia DNS-over-QUIC (DoQ) osiągalny przez zdalnego klienta DoQ w trybie wielowątkowym. Migracja ścieżki QUIC wywołana przez klienta może wejść w czyszczenie strumienia/połączenia, podczas gdy odpowiedź mesh nadal przechowuje wskaźnik do strumienia DoQ. Czyszczenie zwalnia strumień DoQ, a gdy oczekująca odpowiedź mesh później się kończy, następuje dereferencja nieaktualnego wskaźnika prowadząca do awarii.

NLnet Labs Unbound do wersji 1.26.1 włącznie ogranicza przechodzenie wskaźników kompresji dla każdej pojedynczej operacji na nazwie domeny, ale nie ma zbiorczego budżetu na przetwarzanie dekompresji przychodzącej. Wiele łańcuchowych wskaźników kompresji w wiadomości powoduje duże zużycie CPU. Złośliwy aktor z dostępem do zapytań rekurencyjnych i kontrolą zwykle delegowanego autorytetu, który serwuje specjalnie spreparowane odpowiedzi, może wykorzystać podatność i pogorszyć ogólną wydajność Unbound.

W NLnet Labs Unbound do wersji 1.26.1 włącznie, gdy skonfigurowano zarówno główny trust anchor, jak i dodatkowy 'trust-anchor:' dla strefy island-of-security, której rodzic jest udowodniony jako niezabezpieczony w łańcuchu głównym, złośliwy aktor mogący dostarczyć jedną sfałszowaną odpowiedź NXDOMAIN dla nazwy wewnątrz wyspy, z NSEC/SOA RRSIG 'SignerName' ustawionym na niezabezpieczonego rodzica, oszukuje walidator Unbound, aby użył głównego trust anchor, a następnie niezabezpieczonego rodzica, powodując, że rekord jest traktowany jako niezabezpieczony i odmawia istnienia rekordów w wyspie zaufania.

W NLnet Labs Unbound do wersji 1.26.1 włącznie występuje obserwowalny kanał boczny na poziomie pamięci podręcznej przy konfiguracji 'unwanted-reply-threshold > 0' (nie jest to konfiguracja domyślna). Gdy pakiet UDP przypominający odpowiedź trafi na port źródłowy używany przez zapytanie rekurencyjne, ale jego TXID nie pasuje do żadnego oczekującego zapytania, Unbound zlicza go jako niechcianą odpowiedź i po osiągnięciu progu czyści pamięć podręczną RRset i wiadomości, co pozwala zewnętrznemu obserwatorowi rozróżnić, czy kandydat na port pasuje do bieżącego portu źródłowego.

NLnet Labs Unbound do wersji 1.26.0 jest podatny na ataki typu algorithmic complexity (znane jako 'ReTrap'), które powodują degradację usługi. Ataki obejmują TagTrap (duża liczba niedopasowanych rekordów DNSKEY, RRSIG, DS), DelegationTrap (kosztowna iteracyjna walidacja dla głęboko zagnieżdżonych domen), NsecTrap (nadmiarowe nieprawidłowe rekordy NSEC) oraz AdditionalTrap (domyślna walidacja sekcji ADDITIONAL).

NLnet Labs Unbound od wersji 1.12.0 do 1.26.0 ma podatność use-after-free, gdy jest skompilowany z obsługą DNS-over-HTTPS (--with-libnghttp2). W ścieżkach błędów (np. RPZ drop, jostle) porzucony strumień DoH powoduje awarię całej sesji DoH i nie uwzględnia innych strumieni, prowadząc do use-after-free. Atakujący może to wywołać pojedynczym połączeniem DoH, ale wpływ jest ograniczony, ponieważ odczyty nie są kontrolowane przez użytkownika; jednak zahartowany alokator może wykryć błąd i kontrolowanie zakończyć proces, powodując DoS.