CVE-2026-111496

Kafka Streams wyznacza swój zegar czasu strumienia na podstawie rekordowych znaczników czasu. Funkcja PunstandingSchedule.next() obliczyła następny czas interpunkcji jako sygnatura czasowa + (intervalsMissed + 1) * interwał bez sprawdzania przepełnienia. Rekord ze sygnaturą czasową równą lub bliską wartości Long.MAX_VALUE przyspiesza czas transmisji do tej wartości, więc następna interpunkcja czasu transmisji zostanie przekroczona do czasu ujemnego. Następnie PuncationQueue ponownie umieszcza ten czas w kolejce i zapętla go w nieskończoność, trzymając blokadę, wstrzymując StreamThread.


Wpływ:

Wystarczy jeden rekord. StreamThread, którego dotyczy problem, przestaje przetwarzać, a ponieważ rekord pozostaje w temacie, zawieszenie powraca po ponownym uruchomieniu; aplikacja, której dotyczy to wszystkich partycji, przestaje odpowiadać. Dotyczy to tylko aplikacji Streams, a nie brokerów ani klastra. Aby go uruchomić, potrzebny jest dostęp do zapisu do tematu źródłowego, którego topologia wykorzystuje interpunkcję w czasie strumienia, oraz broker przechowujący rekord: brokerzy z Apache Kafka 4.0.0 domyślnie odrzucają taki znacznik czasu (log.message.timestamp.after.max.ms, jedna godzina), więc jest on osiągalny tylko w przypadku starszych brokerów lub tam, gdzie to ograniczenie zostało złagodzone.


Łagodzenie:

Uaktualnij strumienie Kafka do wersji 4.2.2, 4.3.2 lub 4.4.0. Aby zapewnić głębszą obronę, ogranicz log.message.timestamp.after.max.ms do tematów źródłowych i ogranicz do nich dostęp do zapisu.


Rozdzielczość:

Od wersji Apache Kafka 4.2.2, 4.3.2 i 4.4.0: czas następnej interpunkcji jest obliczany przy użyciu arytmetyki sprawdzanej przy przepełnieniu (przypięty do Long.MAX_VALUE), a przełożona interpunkcja jest ponownie umieszczana w kolejce dopiero wtedy, gdy jej czas przesunie się do przodu.