LINUX.ORG.RU

Новые уязвимости FreeBSD

 , ,


0

2

30 июня 2026 года были опубликованы уведомления об исправлении 13 новых уязвимостей в ОС FreeBSD.

  • CVE-2026-49418. Пользователь с доступом к устройству, имеющему memory-mapped интерфейс, может организовать double-free/use-after-free в ядре. Вероятно, это может привести к повышению привилегий.
  • CVE-2026-49419. (только FreeBSD 15+) Двойное уменьшение refcount текущего jail-а при обработке ошибки обращения к другому jail по jail descriptor-у (появились в FreeBSD 15), приводящее в итоге к незапланированному освобождению управляющей структуры jail-а и последующими use-after-free везде где она используется. Теоретически может приводить к повышению привилегий.
  • CVE-2026-49415. При выполнении setuid-программы права доступа к её памяти устанавливаются чуть позже, чем эта память инициализируется, что позволяет в небольшой промежуток времени получить к ней доступ и отредактировать её, не имея нужных привилегий, через procfs или linprocfs. В большинстве систем procfs, и тем более libprocfs, не монтируются, так что проблема скорее всего мало кого затрагивает.
  • CVE-2026-49429, CVE-2026-49430, CVE-2026-49431. (только для систем с ZFS) Первые две ошибки связаны с выделением памяти некорректного размера: выделяется буфер размером, переданным в виде 32-битного числа, а затем в него записываются данные настоящего размера, что приводит к переполнению, если реальный размер буфера был больше 4ГБ. Обе они могут провоцироваться только root-ом, либо пользователем с явно добавленными привилегиями на уязвимые операции. Третья ошибка доступна для эксплуатации всем, она позволяет кому угодно навесить на датасет флаг «$hasrecvd» с помощью ZFS_IOC_SET_PROP (насколько это опасно, из анонса непонятно).
  • CVE-2026-49420. Отсутствие должной проверки размера пакета перед записью его в буфер фиксированного размера в стеке в libalias-модуле поддержки RTSP приводит к возможности удалённо и без авторизации переполнить стек либо ядра (для ipfw nat) либо процесса natd (который обычно запущен от root). Потенциально может привести к RCE. Спровоцировать уязвимость может злонамеренный хост внутри локальной сети за NAT, реализованном через libalias, шлющий вредоносные RTSP-пакеты. Соответственно, уязвимость не затрагивает хосты, на который не запущен NAT в том или ином виде. А так же: natd перестанет быть уязвимым, если убрать строчку libalias_smedia.so из /etc/libalias.conf и перезапустить natd, а ipfw nat не будет уязвимым без загрузки модуля alias_smedia.ko (там не указано, может ли он его подгружать автоматически). А так же, уязвимый обработчик смотрит только TCP/UDP пакеты, идущие наружу, у которых один из портов 554 или 7070 - если зафарйволить такие пакеты до их попадания в NAT, уязвимость тоже исчезнет.
  • CVE-2026-49421. unlinkat() и funlinkat() не учитывали флаг AT_RESOLVE_BENEATH, который должен был запрещать при проходе данного пути выходить за пределы директории, указанной аргументом dirfd. Таким образом, позволялось удалять файлы за пределами директории, когда вызывающий код хотел данное ограничение ввести.
  • CVE-2026-49422. Гонка в модуле tcp_rack.ko (по умолчанию он не загружен). Каждому tcp-сокету можно индивидуально выбирать tcp-стек, через который он будет работать, в том числе переключая их на лету. Если сделать так: 1) на сокете с tcp_rack вызываем rack-специфичный setsockopt(), 2) в другом треде успеваем быстро переключить tcp-стек с rack на другой и ещё раз переключить обратно на rack в нужный момент времени, то rack-обработчик setsockopt() будет работать со старым (до переключения) адресом структуры состояния сокета, что приводит к повреждению памяти и возможному повышению привилегий. Узявимы только системы где явно загружен tcp_rack.ko, это не дефолт.
  • CVE-2026-49427, CVE-2026-49428. POSIX largepages (shm_create_largepage) при аллокации недостаточно аккуратно размечались как используемые, что могло приводить к их ошибочному освобождению при разных обстоятельствах (упомянуты вызовы sendfile с флагом SF_NOCACHE, open с флагом O_TRUNC и fspacectl) и последующим use-after-free с обычными последствиями.
  • CVE-2026-49426. Некорректные логи audit(4) про удалённые сисколлы через ptrace(PT_SC_REMOTE). Могут запутать системы анализа подозрительных ситуаций, если таковые используются.
  • CVE-2026-49423. Возможный kernel-panic при приёме данных через kTLS с участием TLS 1.2 CBC-записей. Чтобы избежать проблемы, можно сделать kern.ipc.tls.enable=0 или kern.ipc.tls.cbc_enable=0.
  • CVE-2026-49424. Утечка данных (104 байта) из стека ядра при вызове linux-compat waitid(), который забывает обнулять неиспользуемую часть linux-структуры siginfo_t при переносе в неё данных из freebsd-шной. В обычных GENERIC-ядрах linux-эмулятор по умолчанию выключен, и включается только ручной подгрузкой модуля.
  • CVE-2026-49425. Аналогично предыдущему, 32-битное kevent забывает обнулять 32-битную структуру перед переносом в неё данных из нативной 64-битной, что приводит к утечке данных из стека. По умолчанию 32-битная совместимость в ядре включена (не модулем).
  • CVE-2026-58081, CVE-2026-58082. Уязвимости в iconv. Первая: многие его модули не проверяют размер предоставленного вызывающим кодом выходного буфера перед записью в него результата (упомянуты HZ, UTF-7, VIQR, ZW). Вторая: модуль ISO-2022 использует 6-байтовый буфер в стеке для внутренних операций, но в него может быть записано до 10 байт, портя стек. В итоге, запуск iconv для конвертации в или из одной из указанных кодировок с непроверенными входными данными может быть подвержен переполнениям буферов.

>>> FreeBSD Security Advisories

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 1)
Ответ на: комментарий от iZEN

Для тебя сейчас главное - перестать хронически врать и изворачиваться. Покажи пальцем комментарий, в котором я утверждал, что в линуксе всё и всегда свежее. Бегом, я жду.

Пока что мы видели здесь лишь твоё голословное, ничем не подкрепленное утверждение о неоспоримой свежести фряшных портов, и больше ничего.

liksys ★★★★
()
Ответ на: комментарий от rsync

это ИИ все уязвимости нашла или люди?

ЛюдИИ... ;)))

Somebody ★★★★
()
Ответ на: комментарий от liksys

И даже для серверов FreeNAS сделали, но BSD был в проде настолько никому не нужен, что в итоге стали выпускать версию на Debian.

А ты знаешь историю FreeNAS, почему так случилось? Расскажи — вместе поржём.

(FreeNAS не является частью проекта FreeBSD. Это — отдельная инициатива частной коммерческой компании.)

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от liksys

Пока что мы видели здесь лишь твоё голословное, ничем не подкрепленное утверждение о неоспоримой свежести фряшных портов, и больше ничего.

Всё подкреплено. Я даже вчера ради интереса thunderbird протухший на минор нашёл в Арче, в то время как на FreeBSD он свежий. Так что +1 в пользу FreeBSD на десктопе.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Ты такой забавный, когда пытаешься отрицать реальность.

FreeNAS не является частью проекта FreeBSD. Это — отдельная инициатива частной коммерческой компании

Всё правильно. Коммерческая компания поняла, что ее клиентам FreeBSD не уперлась, и сконцентрировала усилия на том, чтобы перейти на линукс. В принципе, так происходит с подавляющим большинством компаний. И даже серверную инфраструктуру переводят с фряхи на линукс просто из-за того, что по линуксу доступно больше экспертизы и меньше приходится пердолиться с выпиливанием из фряхи лобзиком конфетки.

Так, например, яндекс закопал фряху в инфраструктуре.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от iZEN

Всё подкреплено.

Это враньё, разумеется. И я всё еще жду, когда ты подтвердишь другое свое враньё о том, что я якобы утверждал, что в линуксе всё и всегда свежее. Ну-ка, м?

Я даже вчера ради интереса thunderbird протухший на минор нашёл в Арче, в то время как на FreeBSD он свежий. Так что +1 в пользу FreeBSD на десктопе.

А это называется «черрипикинг» и «натягивание совы на глобус». Реальность же в том, что ты можешь найти устаревший софт как в одном сборнике пакетов, так и в другом. И это абсолютно никак не влияет на готовность к десктопу, которая определяется в первую очередь тем, насколько система поддерживает современное железо и насколько сложно с ней работать слабоподготовленному юзеру.

liksys ★★★★
()
Ответ на: комментарий от liksys

доступно больше экспертизы

Зачем им всем экспертизы какие-то проводить? Пользоваться обычно надо.

с выпиливанием из фряхи лобзиком конфетки.

Дело в том что из фрибсд сделать нужную систему относительно просто, из линукса же требует огромных усилий т.к. куда ни посмотри все или инопланетное или кривое. Большинство как раз совсем даже не пытаются делать что-то нормальное, им надо установить в два клика что-нить кое-как работающее и кое-как пересекающееся с реальными потребностями. Такого в линуксе больше, да.

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

Зачем им всем экспертизы какие-то проводить? Пользоваться обычно надо.

Ты специально шлангуешь, или не знаешь общеупотребимых терминов?

Дело в том что из фрибсд сделать нужную систему относительно просто

Очень сильно зависит от критерия «нужности». Я хочу взять малину поставить на нее фряху и кодировать на ней H.264 на GPU. На линуксе это есть, как мне сделать то же самое на фряхе?

куда ни посмотри все или инопланетное или кривое

Зато решения в принципе существуют, в отличие от.

liksys ★★★★
()
Ответ на: комментарий от liksys

Ты специально шлангуешь, или не знаешь общеупотребимых терминов?

Это тебе такой вопрос.

Я хочу взять малину поставить на нее фряху и кодировать на ней H.264 на GPU. На линуксе это есть, как мне сделать то же самое на фряхе?

Не надо смешивать эмбед-прошивки и ОС для компьютеров. Фрибсд вроде как не для эмбедов, хотя и местами работает на таких устройствах.

Зато решения в принципе существуют, в отличие от.

От «в принципе существования» какой-то кривоты не особо толку, если тебе нужен нормальный продукт. Там легче заново с нуля написать много чего чем исправлять.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Это тебе такой вопрос.

Нет, не мне. Это общеупотребимый в айтишечке термин, значения которого ты не знаешь, или просто делаешь вид, играя в нетакусика-борцунишку за чистоту языка.

Не надо смешивать эмбед-прошивки и ОС для компьютеров. Фрибсд вроде как не для эмбедов, хотя и местами работает на таких устройствах.

Ну началось виляние жопой. «Это вам не нужно», «то не для этого», «сюда не ходи», «туда не смотри». Хорошо, другой пример: я могу поставить на фряху стим и поиграть в какие-нибудь виндовые игры?

Там легче заново с нуля написать много чего чем исправлять.

Не легче, когда писать нужно много. Проще точечно отладить, заслать патчи и пользоваться. Потому что для юзера нормальный продукт - это тот, который решает его проблемы, хорошо выглядит и не глючит. А насколько оно там внутри красиво написано - юзера интересует в последнюю очередь.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

Нет, не мне. Это общеупотребимый в айтишечке термин

Это не термин, а вполне обычное слово.

я могу поставить на фряху стим и поиграть в какие-нибудь виндовые игры?

Не пробовал. Впрочем, wine там работает (я пользуюсь). Но если что не путай меня и iZEN, это он пишет что фрибсд дестопно полностью поддерживается, а я писал наоборот. И если там не будут работать игры - не удивлюсь.

Не легче, когда писать нужно много. Проще точечно отладить, заслать патчи и пользоваться.

По-разному бывает.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от liksys

А это называется «черрипикинг» и «натягивание совы на глобус».

Лору пора поменять маскота с туха на сову натянутую на глобус и прозвать её Fill-in :D

ant1
()
Последнее исправление: ant1 (всего исправлений: 1)
Ответ на: комментарий от firkax

От наличия у тебя определенных заблуждений, данный термин никуда не исчезнет. То, что ты отрицаешь широко употребляемые термины из индустрии - это сугубо твои личные проблемы.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

И тем не менее, это не термин, а обычное слово. О чём ты пишешь я понимаю - но там это тоже не термин, а обычное английское слово, обманка для переводчиков, такое же как magazine - журнал (а не магазин), или silicone - кремний (а не силикон), например. Правильный его перевод на русский язык - экспертность.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Правильный

Нет. Правильно то, что устоялось в общении. Бариста - склоняется, кофе - оно. Оба слова - недоадаптированные заимствования. «Экспертиза» - точно такое же прямое заимствование словоформы. Большинству плевать на «экспертность», они пользуются «экспертизой».

liksys ★★★★
()
Ответ на: комментарий от liksys

Нет. Правильно то, что устоялось в общении.

Я чуть чуть подушню, хотя по самой сути я и согласен: правильно то, что соответствует установленным правилам. Так что именно конкретно это возражение не совсем корректно. Но да, это не повод держаться за «правильное» в угоду удобству. Удобство важнее.

CrX ★★★★★
()
Ответ на: комментарий от CrX

Тут есть нюанс. Правила являются формализацией устоявшегося подхода, которым пользуется большинство. Конкретно правила русского языка и добавление слов в словари осуществляется соответствующими комиссиями по факту их употребления. Словари априори будут отставать от живой речи.

liksys ★★★★
()
Ответ на: комментарий от liksys

Всё так. Сперва слово или вариация становится общеупотребимой, а потом правильной.

CrX ★★★★★
()
Ответ на: комментарий от firkax

Еще как устоялось. По всей индустрии слышал, с кем ни общался.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.