Новые исправления уязвимостей в FreeBSD

И как обычно - куча ошибок памяти: use after free, out of bound и прочие null dereference.

Но раст не нужен, твердо и четко.

Раст не особо нужен – нужен ИИ.

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

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

Но ИИ ловит только простые проблемы и не может в сложную логику

Ага, именно поэтому сплошной поток обнаруженных критических проблем в системных компонентах совпала с появлением качественного ИИ уровня Opus 4.5 и выше. Совпадение.

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

Машине пофиг на язык, она не устаёт, не испытывает боли от написания и чтения кода, работает 24/7.

Именно так: модели развились достаточно, чтобы искать простые ошибки. Достаточно посмотреть на описание оных ошибок и код.

развились достаточно, чтобы искать простые ошибки

А люди в такой логике, видимо, развились недостаточно.

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

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

язык с относительно нормальной системой типов для исключений проблем с памятью

Это и называется «исключающий ограниченный подкласс ошибок».

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

А зачем ты заставляешь его генерировать слоп? :)

Лол, ну не фряху же в новости про фряху обсуждать xD

Обсуждать фейлы бзд гораздо интереснее. Хотя я предпочитаю опенка и список того, что там не изобрели, по сравнению с линуксами.

А если серьёзно про Раст ответить, то:

CVE-2026-84782. Юзерспейсная уязвимость в openssl при использовании DTLS. Может приводить к отправке в сеть содержимого памяти за пределами буфера или к сегфолтам, если за пределами буфера памяти нет.

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

CVE-2026-101302. Уязвимость в ядерном TLS. Злонамеренный удалённый TLS1.3-хост может спровоцировать kernel panic.

Уже и так паника ядра, без Раста справились.

CVE-2026-58098. Race в semop(2), с его помощью можно было сделать use-after-free и теоретически повысить привилегии. Надо отметить, что ещё совсем недавно исправлялась очень похожая ошибка в semctl(2).

CVE-2026-58099, CVE-2026-58100 (только FreeBSD 15.1) Ошибки в реализации KQUEUE_CPONFORK могли приводить к use-after-free и подобному при race, что теоретически может позволить повысить привилегии. 

Всякая многопоточная/асинхронная дрянь – такие штуки без unsafe не пишутся. Раст не особо поможет.

CVE-2026-101304, CVE-2026-101305, CVE-2026-101306. Разные уязвимости, позволявшие сбросить с файлового дескриптора директории флаг FD_RESOLVE_BENEATH (запрещающий переходить по ".." из него), что позволяло сбежать из файловой системы контейнера, если есть сообщник в другом контейнере, с которым есть связь через UNIX-сокет (сообщник мог прислать дескриптор своей директории, которая для другого контейнера получалась уже не ограничена). 

CVE-2026-101303. Сисколл sendto() для UDPv6 не исправлял адрес назначения пакетов, которые программа в контейнере (jail) хочет отправить на loopback-адрес (а должен заменять их на адрес контейнера), что позволяло контейнеризованной программе общаться с хостовыми сервисами, слушающими локалхост по UDPv6. Данная уязвимость не затрагивает протоколы с установлением соединения (TCP), не затрагивает IPv4 и не затрагивает контейнеры с виртуализованным сетевым стеком.

Логические ошибки, Раст никак не поможет.

Как минимум полторы ошибки будут исключены - это уже хорошо.

Скоро ИИ заменит всех мамкиных хакеров, и тогда раст будет не особо нужен.

Ну-ну.

Боишься?))

Хотя я предпочитаю опенка и список того, что там не изобрели, по сравнению с линуксами.

Там Тео RESOLVE_BENEATH изобретает: https://www.opennet.ru/opennews/art.shtml?num=66401

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

С этим кстати такая история: изобрели его в фрибсд (O_RESOLVE_BENEATH), затем стащили в линукс (RESOLVE_BENEATH), а Тео в 2025-05-28 предложил O_BELOW и черновик патча (так что на опеннете новость только в том что эту идею годовой давности теперь воплотили в почти-релизный код), ссылаясь в том числе на опыт фри и линукса. И при обсуждении бага с jail-ами тоже год назад (сам баг я зарепортил ещё в 2022) один из участников обсуждения предложил внедрить аналог O_BELOW для противодействия данной проблеме (про то что O_BELOW заимствован из уже существующего в фре O_RESOLVE_BENEATH он либо не знал, либо посчитал его недостаточным, там чуть отличается семантика). А третий пункт списка этой темы - продолжение дофикшивания той проблемы.

Пара тонн веществ - хватит на все датацентры.

Нет, потому что во-первых - не заменит, а во-вторых - я кабан-кабаныч %)

RESOLVE_BENEATH

Ничоси, 2026 год, пора!

я кабан-кабаныч %)

боров что ли?))

во обRUSTел

UDPv6

о как. познаём мир вместе лором😊

Лучше бы драйвера для wifi6 портировал…