22 октября 2026 Ubuntu выпустила USN-8954-1. Ali Firas нашёл, что zlib криво обрабатывает отдельные неблокирующие записи. Программа из-за этого может упасть. Если атакующему повезёт с раскладкой памяти, в ней запустят чужой код (heap overflow). Карточка одна, CVE-2026-85091.
В шапке бюллетеня формулировка короче. zlib можно заставить упасть или запустить программы, если на вход придёт специально собранный поток. Приоритет Ubuntu стоит Medium. На карточке рядом две оценки: CVSS 3.1 равен 7.4 (High), CVSS 4.0 равен 8.3 (High). Вектор 3.1: сеть, сложность атаки высокая, привилегии не нужны, пользователь ничего не нажимает, область не меняется, конфиденциальность не задета, целостность и доступность страдают сильно. Целиком он такой: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H. Слово High тут меньше значит, чем высокая сложность (AC:H). До ошибки доходит тот, кто попадает в gzwrite после остановки записи, а не любой запрос к главной WordPress.
Ошибка в функции gz_vacate(). В описании названы zlib с 1.3.1.2 по 1.3.2. Ломается неблокирующий gzwrite(), когда снаружи остался старый указатель на буфер. gzprintf() или gzvprintf() после того, как запись встала, гоняет memmove() за границу внутреннего входного буфера.
Касается это пакета zlib1g. Его зовут PHP, который пишет .gz, утилиты бэкапа, git, apt и любой свой демон, собранный с libz. Сжатие ответа в nginx и zlib.output_compression в PHP идут через deflate. В карточке назван путь gzwrite и gzprintf. Это другой вход: в gzip on и в кэше страниц искать ту же ошибку не стоит. Разбирать каждый бинарник на символ gzprintf перед обновлением незачем. Пакет маленький.
Пакеты в USN-8954-1
Закрыты три релиза. На каждом одна и та же восьмёрка из исходника zlib: zlib1g, zlib1g-dev, lib32z1, lib32z1-dev, lib64z1, lib64z1-dev, libx32z1, libx32z1-dev. На обычном amd64 VPS без multiarch живой пакет один, zlib1g. Заголовочный zlib1g-dev нужен, только если на сервере что-то собирают. lib32, lib64 и libx32 появляются, когда включены чужие архитектуры. Версия у всех восьми внутри одного релиза одинаковая.
- Ubuntu 26.10 (stonking):
1:1.3.dfsg+really1.3.2-3ubuntu1.1 - Ubuntu 26.04 LTS (resolute):
1:1.3.dfsg+really1.3.1-1ubuntu3.2 - Ubuntu 24.04 LTS (noble):
1:1.3.dfsg-3.1ubuntu2.3
Ubuntu пишет, что хватает обычного обновления системы. Блок с патчем на карточке CVE помечен как справка: накладывать обновление вручную не советуют, берите пакет из репозитория.
По строке версии видно разницу веток. 26.10 везёт 1.3.2, это как раз верх диапазона из описания CVE. 26.04 везёт 1.3.1, не 1.3.1.2. 24.04 остаётся на 1.3: в имени нет really1.3.1. И пакет для noble всё равно вышел.
Так выходит из заметок на карточке. mdeslaur пишет, что по тексту описания версии ниже 1.3.1 вроде бы не затронуты, но воспроизведение роняет 1.3.0 так же, как 1.3.1. Более тяжёлый вариант, по этой заметке, появился в 1.3.1.2, коммит 81cc0be. Заметка mrmajumder от 22 октября 2026: текущий патч авторов zlib наложили на 1.3.1 и новее, а по версиям ниже решение ещё не закрыто, они тоже могут быть затронуты. Поэтому noble получил 1:1.3.dfsg-3.1ubuntu2.3, хотя описание CVE в первом абзаце говорит про диапазон 1.3.1.2-1.3.2. В таблице статус этих трёх релизов уже Fixed.
Jammy: статус Needs evaluation
У пакета zlib на 22.04 LTS (jammy), а также на 20.04, 18.04, 16.04 и 14.04 в таблице стоит Needs evaluation. Номера исправленной версии рядом нет, и в USN-8954-1 этих релизов нет. Много боевых VPS с WordPress всё ещё на jammy.
Пакет noble на jammy не переносится. Зависимости и символы другие, бюллетень такого перехода не описывает. Пока строка jammy не станет Fixed, в репозитории 22.04 нет zlib1g с фиксом из USN-8954-1. apt upgrade поставит то, что jammy считает текущим. Это не номер 1:1.3.dfsg-3.1ubuntu2.3.
Ждать имеет смысл обновления той же карточки, а не сборки zlib из git на проде. Команда Ubuntu как раз просит не тащить патч отдельно.
klibc, zsync и rsync
USN обновляет исходный пакет zlib. На карточке CVE рядом три другие строки, и этим бюллетенем они не закрываются.
klibc помечен Vulnerable на всех перечисленных релизах, от 26.10 до 14.04. Исправленной версии в таблице нет. Это маленькая libc из initramfs, не та libz.so.1, которой nginx жмёт страницы. Сайт из-за klibc сам по себе в интернет не торчит. apt install zlib1g эту строку не снимает. Пока у klibc нет своего Fixed, initramfs живёт со старой копией.
zsync на 26.10, 26.04, 24.04, 22.04, 20.04, 18.04 и 16.04 тоже Vulnerable. Пакета с фиксом в USN нет. На типичном сервере с WordPress zsync часто просто не установлен. dpkg-query -W zsync либо покажет версию, либо скажет, что пакета нет. Нет пакета, нет и этой копии библиотеки.
С rsync история другая. В заметке mdeslaur прямо сказано: начиная с 3.2.0-1 rsync собирается с системным zlib. На 26.10, 26.04, 24.04 и 22.04 статус Not affected. На 20.04, 18.04 и 16.04 rsync помечен Vulnerable, там своя копия внутри пакета. У 14.04 для rsync стоит Not affected. На 24.04 после обновления zlib1g системный rsync подхватит новую библиотеку вместе с остальными процессами, отдельный пакет rsync из этого USN не выходит.
Как обновить zlib1g
Сначала номер, потом обновление. Полный dist-upgrade ради одной библиотеки не обязателен. Если включены unattended-upgrades, пакет на 24.04, 26.04 или 26.10 мог уже приехать. Расхождение видно в кандидате apt-cache policy: он должен совпасть со строкой из USN, а не просто быть новее, чем вчера.
dpkg-query -W zlib1g apt-cache policy zlib1g sudo apt update && sudo apt upgrade
На 24.04 в выводе ждёте 1:1.3.dfsg-3.1ubuntu2.3. На 26.04: 1:1.3.dfsg+really1.3.1-1ubuntu3.2. На 26.10: 1:1.3.dfsg+really1.3.2-3ubuntu1.1. Если apt пишет, что zlib1g и так последней версии, а номер старый, кандидат в policy смотрит не в тот карман. Обычно это отстающее зеркало или неподключённый репозиторий security. Чужой deb с другого релиза Ubuntu сюда не подкладывайте.
Тот же пакет можно поднять точечно: sudo apt install --only-upgrade zlib1g. Стоят lib32z1, lib64z1 или libx32z1, их версии в бюллетене те же. --only-upgrade не поставит пакет, которого на машине не было, так что дописать имя к apt install безопасно: обновится только то, что уже стоит. zlib1g-dev имеет смысл поднять вместе с библиотекой, если компилятор на сервере ещё жив. Иначе следующая сборка возьмёт старые заголовки к новой libz.
Файл на диске и код в памяти это разные вещи. Процесс, который уже загрузил libz.so.1, работает со старой копией, пока сервис не перезапустят. У nginx новые worker появляются после reload, и они читают библиотеку заново. Перед reload есть смысл прогнать nginx -t. php-fpm так же: reload того пула, который реально обслуживает сайт. Версии PHP 8.3 и 8.4 в этом обновлении не смешивайте. MariaDB и mysqld увидят новую libz после restart сервиса. Это короткая остановка записей, её ставят в своё окно. В инструкции к бюллетеню достаточно обычного обновления системы.
На 22.04 те же команды покажут пакет jammy. Сверяйте его со статусом Needs evaluation, а не с номерами noble и resolute. Пока Fixed для jammy не появился, эти команды ошибку на 22.04 не закрывают.
Для живого сайта на 24.04, 26.04 или 26.10 ход обычный. Поднять zlib1g до версии из USN-8954-1, перезапустить сервисы, которые уже держат библиотеку, и не считать, что klibc с zsync закрылись заодно. Приоритет Medium и высокая сложность атаки пакет не отменяют: общую библиотеку дешевле обновить, чем выяснять, кто на этой машине зовёт gzprintf.
