Уязвимости в Linux и FreeBSD, позволяющие получить root-доступ в системе

Уязвимость (CVE не назначен) в модуле ntfs3

Это же Paragon'овский драйвер?..

Да.

Всего за август раскрыта информация о 1668 уязвимостях в ядре Linux.

Я ж правильно понимаю, что это теперь бытие всего опенсорса, на нем так и будут тренироваться делать «недырявое ПО по версии ЫЫ»

ЗЫ Кто-нибудь, заставьте их написать 1668 эксплоита, и чтоб они работали не в границах «коня в вакууме»…

Нет.

Нет.

Ну если они ЫЫшкой ковыряют отдельные функции, они ж так до скончания веков будут «дыры» находить, это испытание просто не способно пройти ни одно ПО на планете, даже «хелло ворлд»…

Нашли бездонный источник «показушной нужности»…

Эти «эксперименты» либо линукс сломают, либо из него тормозную и лагучую недоОСь сделают…

Меня озарило:

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

Всего за август раскрыта информация о 1668 уязвимостях в ядре Linux.

ИИ-шечка уже напейсала эксплойты к большинству из них?

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

Ну сколько можно...

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

Любопытно, что раньше подобный аргумент использовали в пользу опенсорса. «Закон Линуса» гласит, что «given enough eyeballs, all bugs are shallow». С ИИ же шансы многомиллионного сообщества и шайки блэкхэтов могут уравняться. Надежда только на корпоративно-тоталитарную цензуру, ограничивающую свободный доступ к наиболее «опасным» моделям (как с Claude Mythos), на фильтрацию «злонамеренных» запросов, и на то, что у корпоратов больше токенов для закрытия уязвимостей в «своих» продуктах, чем у жуликов-индивидуалов, пытающихся их сломать.

С другой стороны, ломать можно и без кода, имея лишь бинарники. Это сложнее, но с агентными воркфлоу нет ничего невозможного. Если ИИшку научить реверс-инжинирингу и дать возможность использовать отладчики и эмуляторы CPU, дыры найдутся даже там, где на уровне ЯП всё чисто. Вот такое будущее.

Зачем фрибсдшные CVE в обратном порядке? И последняя ссылка на openssl битая.

Касательно уязвимостей FreeBSD, уточнения и местами более нормальные описания, если кому интересно:

CVE-2026-58089 (hwpmc) - вроде фатального ничего не происходит, пароли и прочие секретные штуки с помощью этого не украсть, разве что «атаки по сторонним каналам» (типа подсчёт количества каких-то операций и затем угадывание какой rsa-ключ только что считался), ну и драйвер hwpmc по умолчанию не загружен

CVE-2026-58090 (AF_UNIX SOCK_STREAM) - use-after-free, но только 15.0+, те кто заботится о надёжности с установкой новых релизов не спешит, 14.х ещё не снято с поддержки

CVE-2026-58091 (sound) - use-after-free, но для серверов неактуально, на них обычно вообще никаких звуковых карт нет, не говоря уж о нескольких

CVE-2026-58092 (mac_do) - позволяет установить себе группу wheel, однако только при условии что этот mac_do предварительно вообще настроен администратором и при условии что у злонамеренного юзера не было ни одной вторичной группы (обычно они есть), ну и только в версиях 15.х. Установка группы wheel вне контейнера может открыть доступ к использованию su (но рут-пароль надо знать), больше вроде дефолтно-опасных последствий нет. В контейнере скорее всего вообще ни на что не повлияет.

CVE-2026-58095, CVE-2026-58096, CVE-2026-58097 (ppp) - юзерспейс, вектора атаки два: 1) юзер легитимно запустил pppd чтобы подключиться куда-то, а на том конце злонамеренный пир использовал дыру и взломал этот pppd, который запускается с setuid-root, 2) злонамеренный локальный юзер, присутствующий в группе network, злонамеренно запустил pppd и подсунул ему эксплойт чтобы повысить привилегии. В целом, это всё малоактуально, на серверах тем более.

CVE-2026-58093 - с помощью race в ioctl TIOCSCTTY можно прилинковать процесс к терминалу, который уже удаляют, по итогу получаем use-after-free и, как следствие, возможное повышение привилегий - в отличие от всего предыдущего это реально критическая уязвимость.

CVE-2026-58094 — с помощью race в ioctl FIOSSHMLPGCNF (настройка размера largepage size) можно сделать одновременно два таких запроса, которые в итоге устроят в ядерном описании страницы битое состояние, потенциально может привести к повышению привилегий, и это вторая и последняя критическая уязвимость в этом списке.

CVE-2026-18798, CVE-2026-54874, CVE-2026-63072, CVE-2026-63073, CVE-2026-63074, CVE-2026-63075, CVE-2026-63076 (openssl) - юзерспейс, ну openssl как всегда, но скорее всего будет сидеть в контейнере; основной итог - краши рабочих процессов, некоторый шанс RCE расстраивает

Какое же зло этот ии.

Оба линуксовых CVE неактуальны для debian 11, а второй неактуален и для debian 12. Вот так вот, любители самых новых версий.

Почти все ошибки - про память.

Но раст не нужен, главное помнить об этом.

Rust с unsafe не нужен, да..

Ибо шило на мыло.

Unsafe в расте используется для избранных мест. А в сях unsafe - это весь код. Разницу ощущаешь?

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

Почти все ошибки - про память.

Но раст не нужен, главное помнить об этом.

К расту основная претензия ни как к языку, ибо он попадает под категорию «очередной убийца С/С++»…

К расту основные претензии:

• лицензия

• централизация

• Стандарт, который бы хоть пару лет просуществовал (он же постоянно меняется, это буквально вечная бетта, если не фиксируется toolchain)

• его, не смотря на вышеперечисленное, активно внедряют в низкоуровневые и критичные компоненты опенсорс-проектов, а финансируется он при этом корпоратами, среди которых есть даже отметившиеся «не любовью» к опенсорсу

Драйвера состоят не только из пердолинга с регистрами и памятью, но еще и из логики. Совершенно очевидно, что если с первым ничего особо не поделаешь, то второе точно можно защитить. Еще раз: си целиком состоит из unsafe. В любом коде на расте unsafe заведомо меньше, чем в си.

Еще раз: си целиком состоит из unsafe. В любом коде на расте unsafe заведомо меньше, чем в си.

Ничто тебе не мешает писать на Си в safe, делай библиотечку и вперед, если уж на то пошло…

ЗЫ я даже классы могу к Си прикрутить - это не проблема, даже можно llvm какую под это дело придумать, чтоб «как в расте»

лицензия

Что не так с лицензией?

централизация

Откручивается при необходимости, как это сделано в ядре.

Стандарт, который бы хоть пару лет просуществовал

Ну давайте подождем еще лет двадцать, действительно, и наплодим еще больше небезопасного кода.

активно внедряют в низкоуровневые и критичные компоненты

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

финансируется он при этом корпоратами

Корпорации, финансирующие сишников - хорошо. Корпорации, финансирующие растовиков - плохо. Смотри не перепутай.

К корпорациям нужно относиться, как к источнику бабла. Бери и делай хорошо для себя.

Ничто тебе не мешает писать на Си в safe

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

даже можно llvm какую под это дело придумать, чтоб «как в расте»

Хорошо, иди придумывай, разрешаю. Как придумаешь - сделай пейпер.

ничто не мешает писать на машине тъюринга аккуратно

всё таки rust имеет очень злой пэйлоад при том что его обёртка реально лучше чем практикуемый безграмотными Си-код

так и живём

Что не так с лицензией?

Это permissive-лицензии, поэтому Rust можно свободно:

    использовать в коммерческих и закрытых проектах;
    изменять;
    распространять;
    включать в проприетарное ПО;
    использовать без обязательного открытия исходников собственного проекта.

Откручивается при необходимости, как это сделано в ядре.

Пока что откручивается….

Ну давайте подождем еще лет двадцать, действительно, и наплодим еще больше небезопасного кода.

Я согласен подождать, нежели остаться с Не собираемыми гпл-проектами, которые будут требовать раст, к которому может не оказаться доступа

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

БОльшая часть cve - высосана из пальца ЫЫ, да и те «проблемы» вполне решабельны в пределах Си

Корпорации, финансирующие сишников - хорошо. Корпорации, финансирующие растовиков - плохо. Смотри не перепутай.

Путаешь палец и не палец, ибо лицензия у этих продуктов Разная и финансирование влияет По-разному…

К корпорациям нужно относиться, как к источнику бабла. Бери и делай хорошо для себя.

Опять мимо, ибо корпорации всю их историю как к «источнику бабла» относятся к тебе, а сами они «лишних» трат не имеют, иначе бы разорились…

если совсем упрощать

код реально должны писать в условиях 4килооктетов хватит на всё

а пользоваться на машинах с петобайтами

иначе в экономике выжигается в первую очередь самый даровой рессурс

за 70+ лет в ойти очевидно (уже лет как 40 закону Вирта что свистоперделки замедляют софт быстрее чем мурчит закон)

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

Ну давай, продемонстрируй.

Хорошо, иди придумывай

Так это Возможно или Нет?

А если Возможно, то почему «раст»…?

zig > rust

ибо rust форсят собственники DoD

Это permissive-лицензии, поэтому Rust можно свободно:

И в чем проблема? Всё то же самое можно делать и с сишечкой.

Пока что откручивается….

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

Я согласен подождать, нежели остаться с Не собираемыми гпл-проектами, которые будут требовать раст, к которому может не оказаться доступа

Это какая-то шизофрения. Почему не оказаться доступа-то? Чем это концептуально отличается от любого интернет-репозитория с исходниками?

БОльшая часть cve - высосана из пальца

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

Путаешь палец и не палец

Не путаю, конечно же.

финансирование влияет По-разному…

«Это другое» и прочая ментальная гимнастика, я тебя понял.

Опять мимо

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

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

если совсем просто если бы предохранение памяти было бы единственным основанием то старых поцкаль-языков с контролем границ массивов ( а этого и в Лавлейс графине было ) было бы достаточно

rust это религия :(

И в чем проблема? Всё то же самое можно делать и с сишечкой.

Пробуй, узнаешь почему гпл называют «вирусной»…

Вот когда перестанет - тогда и приходи.

Тогда уже поздно будет ибо ↓

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

Это Ты написал, если что…

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

Твой ЫЫ совершает куда более существенные ошибки (как правило прям по «фундаменту»). И пока нет работающего не в вакууме эксплоита - нет реальной cve, а потенциальных ты можешь искать до скончания веков, т.к. «заплатки» будут стимулировать появление других cve

Не путаю, конечно же. «Это другое» и прочая ментальная гимнастика, я тебя понял.

Конечно путаешь, т.к. можно финансировать производителя оружия против себя, а можно финансировать производителя оружия для защиты себя - и там и там финансируешь производителя оружия… Вроде разницы нет по-твоему?

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

Так ты не в состоянии оспорить мой тезис, я верно понял…?

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

Хорошо, я перефразирую и разделю для тебя последовательность вопросов/тезисов:

Я утверждаю, что на Си это Возможно сделать, т.к. на Си уже были выполнены и более сложные проекты.

Ты готов оспорить Это утверждение…?

Если ты не можешь оспорить мое утверждение (я просто Очень уверен, что «Возможно»), то у меня возникает второй закономерный вопрос:

А если Возможно, то почему «раст»…?

PS Так понятнее, когда расписал…?

Пока что откручивается….

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

Как там, кстати, ментейнера Rust в ядре вернули/заменили, который обиделся, что его заставляют ошибки исправлять и ушёл хлопнув дверью?

Мне вообще кажется, что Rust в ядро так активно пропихивали исключительно пиара ради. На практике на данный момент никто его там использовать не собирается.

Пробуй, узнаешь почему гпл называют «вирусной»…

Опять какие-то абстрактные визги. Мне ничто не мешает собирать коммерческий код с помощью GCC, и ничто не мешает линковаться с кодом, лицензии которого это позволяют. Поэтому я тебя еще раз спрашиваю: в чем проблема? Ты сам-то в курсе, или просто теоретизируешь?

Это Ты написал, если что…

Я написал, что именно поэтому не перестанет. Перечитай еще раз, если не понял.

Твой ЫЫ

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

И пока нет работающего не в вакууме эксплоита

У тебя отрицание реальности. За прошлые три месяца уже было найдено куча CVE с ошибками памяти, в том числе - с работающими эксплоитами.

Конечно путаешь

Нет.

Так ты не в состоянии оспорить мой тезис, я верно понял…?

Ты не в состоянии этот тезис даже внятно сформулировать.

Я утверждаю, что на Си это Возможно сделать, т.к. на Си уже были выполнены и более сложные проекты.

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

PS Так понятнее, когда расписал…?

У тебя проблемы с логикой. Она отсутствует.

Опять какие-то абстрактные визги. Мне ничто не мешает собирать коммерческий код с помощью GCC, и ничто не мешает линковаться с кодом, лицензии которого это позволяют.

Визжих пока что тут только ты, вон даже стрелки перевел с лицензии GCC на лицензию «абстрактного тобою писанного кода»

Поэтому я тебя еще раз спрашиваю: в чем проблема? Ты сам-то в курсе, или просто теоретизируешь?

Разувай глаза, речь идет про Реальность, и претензия к лицензии всего инструментария раст

Я написал, что именно поэтому не перестанет. Перечитай еще раз, если не понял.

Ну то есть ты считаешь что это возможно, но помешает «иначе невозможно будет компилять низкоуровневый системный код.» - А что если Кому-то таки доступ Оставят…? Тот сможет компилять код? Ты считаешь, что ты к этим «Кому-то» имеешь прямое отношение?

Я-то все понял, не понятно почему ты противоречишь сам себе и банальную формальную логическую цепочку не вывозишь…

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

С темы не соскакивай, претензия к твоим чаяниям по отношению к ЫЫ. Ты там вообще контекст происходящего не выкупаешь…?

У тебя отрицание реальности. За прошлые три месяца уже было найдено куча CVE с ошибками памяти, в том числе - с работающими эксплоитами.

И? Что ты оспорил? Тебе сказано про Все cve, а ты «в том числе - с работающими эксплоитами»… Значит Не Все cve с эксплоитами? А я тебе на это и кивнул… Я в шоке…

Нет.

Чего неткаешь..? Сказать нечего…?

Ты не в состоянии этот тезис даже внятно сформулировать.

Тезис:

Опять мимо, ибо корпорации всю их историю как к «источнику бабла» относятся к тебе, а сами они «лишних» трат не имеют, иначе бы разорились…

Что тебе кажется не «внятным»??? С чем ты спорить собрался???

ЗЫ это тебе было написано на твое «К корпорациям нужно относиться, как к источнику бабла» в контексте вливания бабла в раст…

Реально сложно…?

Си не подходит для верифицируемых систем. Но вместо того чтоб сделать нормальный си сделали раст.

Раст в ядро пихают ЫЫ фанатики. Потому что у ЫЫ есть особенность: он хорошо учится если его контролирует экспертная система но своим ходом глючит как сотона. Раст а точнее его боров работают именно такой экспертной системой. Поэтому так много компаний одновременно переходят на раст и ЫЫ.

Здесь первая часть твоего утверждения никак не связана со второй

Я дальше читать не буду, давай на пальцах по одной цепочке разбирать.

Если на Си делали проекты сложнее чем уровня «инструментарий раста, раст» (а на Си написаны фактически все распространенные компиляторы, а также ядра ОС и т.д.), то (будь внимателен, ибо тут логическая связь реализуется) Можно было реализовать раст в пределах библиотек и инструментария языка Си (ну был бы Сраст, например)

Ты связь увидел? Оспорить можешь?

ЗЫ А про «И я требую с тебя пруф» - пока забудь, ибо ты пока в простых вещах заблудился, для таких требований сначала надо логическую цепочку выстроить, а то я могу тоже «потребовать, чтоб ты войну и мир перечитал», но это же не суть разговора…?

Визжих пока что тут только ты

Ты, как мы с тобой только что выяснили.

вон даже стрелки перевел с лицензии GCC на лицензию «абстрактного тобою писанного кода»

Не ври. Это ты сказал, что с помощью раста можно писать проприетарный код, и назвал это проблемой. Я сказал, что с помощью си и GCC можно сделать то же самое, из-за чего ты устроил сейчас истерику.

Разувай глаза, речь идет про Реальность, и претензия к лицензии всего инструментария раст

Вот и разуй свои глаза. Почему ты предъявляешь претензию к расту, но не предъявляешь претензию к GCC, шлангу, автотулзам и прочим мейкам, с помощью которых можно делать РОВНО ТО ЖЕ САМОЕ? Или это ДРУГОЕ, я правильно понял твою убогую логику?

Ну то есть ты считаешь что это возможно, но помешает «иначе невозможно будет компилять низкоуровневый системный код.» - А что если Кому-то таки доступ Оставят…? Тот сможет компилять код? Ты считаешь, что ты к этим «Кому-то» имеешь прямое отношение?

Чтобы что, скажи пожалуйста, и как ты себе это представляешь? Что в расте отломают возможность компилять код без их централизованного репа, и в мире одномоментно исчезнут все остальные расты и исходники раста, чтобы это нельзя было форкнуть и запатчить? А тебя вообще не смущает тот факт, что компиляние ядра буквально находится у раста в CI, и компиляться без крейтов - это одна из их важных целей? Откуда у тебя эта шиза в голове?

Я-то все понял, не понятно почему ты противоречишь сам себе и банальную формальную логическую цепочку не вывозишь…

Взаимоисключающие утверждения у тебя, а логику не вывожу, почему-то, я. Дамы и господа, эталонная клоунада.

С темы не соскакивай, претензия к твоим чаяниям по отношению к ЫЫ.

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

Что ты оспорил?

Прочитай сам свой же словесный понос и подумай.

Что тебе кажется не «внятным»??? С чем ты спорить собрался???

Мне кажется, что это суждение совершенно ортогонально тому, что я утверждал в контексте раста, а ты своим межушным нервным узелком до сих пор этого не понял.

Я дальше читать не буду

Думать-то тяжело, ясное дело.

Если на Си делали проекты сложнее чем уровня «инструментарий раста, раст» (а на Си написаны фактически все распространенные компиляторы, а также ядра ОС и т.д.), то (будь внимателен, ибо тут логическая связь реализуется) Можно было реализовать раст в пределах библиотек и инструментария языка Си (ну был бы Сраст, например)

Ты связь увидел?

Связи всё еще нет. Факт наличия сложных проектов не говорит о том, что можно написать библиотечку, которая волшебным образом сделает тебе из сишки раст. Потому что такова природа сишки: unsafe by design. То, что ты вылепишь из нее с помощью макросов и махинация с рантаймом, будет абсолютно несовместимо с уже написанным кодом на си. И совершенно не ясно, какие это даст преимущества по сравнению с растом.

Но мы едем дальше:

Оспорить можешь?

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

Ну давайте подождем еще лет двадцать, действительно, и наплодим еще больше небезопасного кода.

Кстати а что ж это получается: вот в линукс всунули раст, просто какой-то версии которая сдохнет через год и заменится другой. И под эту новую версию весь ядерный растокод будут переписывать? А потом ещё раз? А когда через 10 лет кому-то надо будет собрать антикварную версию ядра, ему придётся ещё и раст нужной версии искать и ставить в мучениях?

который обиделся, что его заставляют ошибки исправлять и ушёл хлопнув дверью?

А что за история?

И под эту новую версию весь ядерный растокод будут переписывать?

У меня ядро NetBSD 9 не скомпилилось новым GCC. И я в мучениях ставил нужную версию GCC.

Претензия абсолютно идентичная.

версии которая сдохнет через год

Что значит «сдохнет через год» и куда делась обратная совместимость?

Хм, gcc портят :(

Говорят же что у раста нет стабильного стандарта.

Думать-то тяжело, ясное дело.

У тебя образование какое, сколько классов?