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)

Нейрослоп нашёёёль!!1

ant1
()

Обнаруженные уязвимости нивелируются в обновлениях актуальных веток FreeBSD -STABLE.

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

нивелируются в обновлениях

Обычно к слову «нивелируются» пишется справа существительное в творительном падеже (нивелируется чем-то).

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

Так ты первый абзац новости то прочёл? Там и написано - уведомления об исправлении. Количество - по количеству официальных уведомлений - их 13 (внизу ссылка на источник). Часть из них содержит внутри больше одного CVE. На опеннете ещё про месяц назад обнаруженное написали, поэтому там 22.

firkax ★★★★★
() автор топика

О, до BSD RIP тоже ИИ-сканеры добрались. Экое отвратное некрофильское ворошение, фи.

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

Читал разумеется (и имеющиеся виртуалки с фряхой обновлены). Однако у тебя 17 CVE в тексте, а не 13 и не 22. На опеннете кстати тоже не совпадает, ну и там и здесь новость о том, что это исправлено, прячется в тексте новости, не попадая в заголовки :)

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

тем не менее, CVE-2026-49420 - повышение до рута, причём даже без локальной УЗ

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

Раньше наказывали за эти три буквы в отношении BSD, или уже снова стало можно? Так я с удовольствием бы это писал под каждой новостью о BSD

I-Love-Microsoft ★★★★★
()

Интересно, я почему-то думал, что он RIPнулся еще в нулевых. А поди ж ты.

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

De mortuis aut bene, aut nihil. De mortuis aut bene, aut male. De mortuis — veritas! «О мёртвых или хорошо, или ничего. О мёртвых или хорошо, или плохо. О мёртвых — правду!»

О BSD - правду! ^_^

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

Прям оригинал-оригинал от самого Хилона до нас не дошёл, но самая ранняя цитата (Диоген) «τὸν τεθνηκóτα μὴ κακολογεῖν». Перевод на латынь с искажением значительно более поздний. Да и в нём вроде как последнй вот этой части тоже не было (тут не уверен, надо перепроверять). Кажется про это «кроме правды» придумали где-то в XXI веке.

upd: погуглил. Не в XXI, а в XIX, похоже. Вот это очень похоже на правду:

это вариант, предложенный Владимиром Фёдоровичем Одоевским, жившим в 19 столетии. А вот для Одоевского источником вдохновения, возможно, послужила фраза Вольтера: “On doit des égards aux vivants ; on ne doit aux morts que la vérité” - «о живых следует говорить уважительно, о мёртвых же - только правду»

Хотя, конечно, требует проверки, нет ли там ещё чего чуть пораньше. Но в любом случае, это додумка прям очень, очень далекая от оригинала.

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

...погуглил...

Как страшно жить рядом с такими вумными ребятишками.

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

Чем пользовался Столлман до эпохи Linux, неужели BSD? Почему тогда ведро для своего GNU он взял Linux если уже пользовался BSD, не пытался его переписать под новой лицензией?

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от pasquale

Типичнейшие С-проблемы.

Истинно так. Хорошо что в линуксе переходят на Rust и там подобного будет всё меньше.

zabbal ★★★☆☆
()
Ответ на: комментарий от I-Love-Microsoft

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

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

Насколько я читал, может инфа моя не верна, как раз драли во все щели авторов BSD в те года, а сам он пользовался тем что есть на работе, и были у него там разные проприетарные unix. Вероятно поэтому он предпочел взяться за то, где оригинальным unix даже за версту не пахнет

I-Love-Microsoft ★★★★★
()

Сдается мне в итоге за безопасностью придется бежать в микроядра, с iommu и поддержкой zerocopy чем сейчас в стаде микроядра мало кто может похвастаться.

А сделать то можно. В своем проце я для этого даже … Хотя нет чего вру… То как там работает mmu сделано для радикального упрощения архитектуры. Но зато когерентный tlb относительно любой записи в порт. Никаких tlb shootdown storms.

ckotctvo
()
Ответ на: комментарий от I-Love-Microsoft

Не понял о чем ты. Мой тезис заключается в том, что заслуги Столмана это почитать существующий bsd код, погулять 2 дня, погладить траву с котом, потом сесть, переписать по памяти и объясвить GPL. Всё.

Почему он так сделал с примерно всеми утилитами кроме ядра, хз. При том, что дядька был реально Mr. Mogoo. Возможно думал, что за мелкие утилиты не посодють, а вот за ведро прилетит по-взрослому, пусть Торвальдс сам отдувается, если что :) Его по этому и в Калифорнию быстренько привезли :)

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

Заслуги столлмана эти gpl и все что с ней связано. Bsd и mit никак бы не продвинули опенсорц. Просто проприетарщики бы были в выигрыше. Это была бы игра в одну калитку

ckotctvo
()
Ответ на: комментарий от ant1

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

Я запоролся на acpi. Это сейчас есть uacpi и глючный кал acpica. А тогда не было. Я бы даже дрова перетащил из хр. Но acpi стало буквально showstopperом

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

Не надо тут. Когда появилось 386BSD… или BSD386…, с ними там черт ногу сломит, тысячи людей стали присылать патчи. Проблемой было эти патчи развернуть, а не принять, опенсорц-то как раз расцветал токо в путь. А Линус подсуетился и продался проприетарщикам по бырому. Тем самым обрек опенсорц впопенсорц когда всякие интелы и нвидии и прочии квалкомы 10% кода открывают, а остальное блобами.

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

Хосспади, я свое ядро за месяц написал для RISC-V. Я, правда, не студент, но ведро пишется на раз-два. Тем более уровня первых линупсов.

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

Молодец возьми с полки пирожок. А написать ядро под х86 можешь? Со всеми тамошними rsdt, madt, facp, dsdt, ssdt, facs…

Легко на раз-два писать ядро когда у тебя нет acpi без которого не заведется даже hpet это таймер если чо. А тогда uacpi не было, и всратого acpica тоже не было. Зато был байт-код aml придуманный шизами и я уверен что за пару дней ты бы все это захерачил

ckotctvo
()
Ответ на: комментарий от ant1

Может быть, а возможно из за драйверов, ведь чтобы они работали нужно соблюсти строгий API, который по памяти не перепишешь а потому было бессмысленно браться

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Торвальдс же взялся. Вопрос почему Штольман зассал. Хотя, может так в наглую как финский студент продаваться не хотел. Берег, так сказать, честь с молоду. Не то что этот.

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

В оригинале это звучит, как «или хорошо, или ничего, кроме правды»

Кто-то неправильно услышал пунктуацию. Вот как надо: «или хорошо, или ничего - кроме правды»

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

А, типа правду об усопшем «не рекомендуется»? И в самом деле, кто скажет родственникам «ваш дед Потап много пил и не отдал мне 5 тыщ долга» хоть это и правда

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от Lucky

В оригинале это звучит, как «или хорошо, или ничего, кроме правды»

Кто-то неправильно услышал пунктуацию. Вот как надо: «или хорошо, или ничего - кроме правды»

В общем, «Что совой об пень, что пнём об сову...»... Смысла-то это не меняет...

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

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

Короче хочешь, чтобы на твоем труде паразитировали корпорации - делай код под BSD лицензией.

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

Первая страница срача, а закон Годвина всё еще не соблюден. Исправляем-с:

«О мёртвых или хорошо, или ничего» - хорошая поговорка, но почему-то перестает работать, когда мы говорим про Гитлера.

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

Так вот именно что. Все эти университетские лицензии - они возникли потому что университет купался в деньгах спонсоров. Им было не просто насрать на outcome - для них было важно засрать все своим говно кодом потому что это цитируемость. Поэтому такие низкие требования к лицензиатам

ckotctvo
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.