Исследователи безопасности из компании Google выявили в ядре Linux уязвимость (CVE-2025-38236), позволяющую повысить свои привилегии в системе. Среди прочего уязвимость даёт возможность обойти механизм sandbox-изоляции, применяемый в Google Chrome, и добиться выполнения кода на уровне ядра при выполнении кода в контексте изолированного процесса рендеринга Chrome (например, при эксплуатации другой уязвимости в Chrome). Проблема проявляется начиная с ядра Linux 6.9 и устранена в обновлениях ядра Linux 6.1.143, 6.6.96, 6.12.36 и 6.15.5. Для загрузки доступен прототип эксплоита...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63710
Останется ли уязвимость, если у файла chrome-sandbox отобрать suid бит?
А ты проверь и отпишись.
А, его там проверять весь Линукс, даже т.б.как 666 же, - построен быть бэкдуром.И Торвальдс тут главный зог, в продолжение оригинальных создатлей Unix помешанных на скверно 666. Да и вокруг него коллектив наверняка из таких же - ибо ведь как говорит народная пословица: друг ждп - сам ждп. Впрочем, кроме просто интернационалистов любых видов, т.к. их за друзей они сами считать не могут, максимум за своих биороботов, как зомбированных дезо-СМИ [и родителями] с детства и в добавок по выплывшим уже давно сведениям - и гипнозом, для на персональном уровне особенно людей при власти. Потому то что, Линукс - open source: хорошо конечно - но, реально совсем не многим лучше даже последних версий давно открыто троянских виндов даже открыто узаконивающих слив под видом телеметрии всевозможных приватных данных и т.б. коммерческой тайны и гос.секретов, т.к. ведь даже самому скомпилировать ядро как прекрасно знают и все пиаристы линукс... надо же - реально не возможно, без использования фактически чётко неявно очерченного компилятора - блобного...
При этом, Торвальдс в подтверждение сказанного - пользуется же по возможности новыми версиями компилятора и значит с всё новыми "стандартми" Сей (т.к.не оригинального же Си стандарта, нео-Си) - что бы усложнить компиляцию [самодельными] альтернативными компиляторами, которым по определению очень тяжело(точней как видим - вовсе не реально) угнаться за этими Си стандартами плюс GCC расширениями, т.к.это потребует не меньше чем ему человеко-часов разработки... т.е. нереально. Значит тут Торвальдс(а, у FreeBSD 666-гомсятины и OpenBSD 666 же шипастыми-бесами на лого [ранее даже куда откровенней] - всё аналогично же уже с Clang) - намеренно делает его ядро не компилируемым без компиляторной блобятины с получается с зашкварно-высокой вероятность быть с злорвредом(ами).
Которая легко [stealth-]вирусуется же - даже при личном компилированием, и т.о. тут значит всё продуманно им(и) - никаких "ой так получись"/случайностей.По сути не очень ясно как даже написать свой компилятор (вообще для любой ОС) чтобы его не завирусовали даже у тебя же на пк или затем сгенерированный им код при раздаче или печати на CD болванку, потому тут тип ОС вообще не имеет значения, значит - надо массово проводить повышение компьютерной грамотности у народа заключающейся в следующем: никакой безопасности не существует в цифровом мире, только ложь о ней для лучшего шпионажа/саботажа, т.о.что особо актуально для банковских... и госсектора т.б.у военных и т.б.следоков! сфер. И все пароли- обман, как говорят - на "честного" вора, тут зловредителя... никакие сертификаты - реально полностью не защищают. Цифровая подпись подлог ещё больший чем бумажная, по кучи причин. И https тут отличный пример. Никаких т.н."Доверенных источников" в сфере ключей шифровании - не только фактически не существует в реальном мире но, и невозможна тайна от них и у них самих на компьютерах - уже только по выше-указанным причинам. Т.о.выходит что, цифровой мир может быть пригоден разве что только для игрушек и прочие развлечений - и то не касающихся вопроса безопасности - пока нету логинов, пролей, видеокамер и микрофона, GPS/акселерометров - в самих устройствах, прочее сознательно диверсия. Вот и наличку уже собираются отменять, в условиях разрастающихся войн означающее потерю всех денег гражданами стран (а, значит в ч.н. кто то станет ещё много богаче).
Это конечно не значит что не надо латать дыры в [Линукс] ядре, но надо понимать что все обновления безопасности или новые версии - полезны(когда конечно новых дыр и залагиваний для искуственного устаревания техники не вставляют, типично), - фактически ничего не стоят. И куда важней действия тут в других сферах.
Да, ошибка на стороне ядра.И в современных системах этот suid бинарник как правило вообще уже не используется. Вместо него давно используется механизм CLONE_NEWUSER, не требующий рут прав.
Хотя в самом CLONE_NEWUSER тоже уязвимости находили, но это уже совсем другая история.
>использовался только в продуктах OracleХаха классика! Опять корпы ядро портят, уязвимости приносят.
Вообще не понимаю зачем подобное нужно было тащить в менлайн - вот Ораклам гужно, пусть в своих локальных ядрах и пользуются.
Думаю если провести тщательный анализ, окажется что таких фичей, нужных только паре человек - с пол ядра.
А ведь все это ненужное нужно еще и поддерживать, а как было бы хорошо снести весь этот зоопарк.
> зачем подобное нужно было тащить в менлайнOOB - часть BSD Socket API. Его чтобы выкинуть нужно сначала книжки переписать. Что-то из серии strcpy заменить на strcpy_s.
Ни кто, ни одному анониму с опеннета, не запретит собрать ядро, в котором будут выпилены все ненужности )))
> Ошибка в реализации MSG_OOB позволяла добиться обращения к
> памяти после её освобождения (use-after-free)Никогда такого не было...
А не, было! Еще как было! Каждый раз одно и тоже.
Ну ладно, не всегда одно и тоже, иногда за пределы буфера выходят :)
> Проблема проявляется начиная с ядра Linux 6.9 и устранена в обновлениях ядра Linux 6.1.143, 6.6.96, ...Что-то тут не то.
А бэкпортируют там чёрте что и чёрте как. Вот когда вейланд поломан на всех прошлых ветках ядер (включая лтс) тут можно забить и ничего бэкпортировать не нужно. Никто ни за что не в ответе в ядре.
Что-то у иксолюбов уже крышу сносит. Какой ещё вяленый в ядре?
"drm/syncobj: fix DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE" with commit hash 101c9f637efa1655f55876644d4439e552267527."drm/syncobj: handle NULL fence in syncobj_eventfd_entry_func" with commit hash 2aa6f5b0fd052e363bb9d4b547189f0bf6b3d6d3.
>> Проблема проявляется начиная с ядра Linux 6.9 и устранена в обновлениях ядра Linux 6.1.143, 6.6.96, ...
> Что-то тут не то.Бекпорты фиксов.
Есть клиенты у которых старые ядра, и которые готовы платить за бекпорт.
Например Ораклу.Посмотри на дату этой новости
opennet.ru/opennews/art.shtml?num=61268
29.05.2024 19:16И вот тебе цитата
"Помимо пакета с ядром из состава RHEL (на базе ядра 4.18) в Oracle Linux предложено собственное ядро Unbreakable Enterprise Kernel 7 Update 2, основанное на ядре Linux 5.15 ..."
> Бекпорты фиксов.А зачем фикс бекпортить, если "проблема проявляется начиная с ядра Linux 6.9"?
Может они вначале забекпортили баг, а сейчас будут бекпортить фикс?))
Фичу могли бекпортировать и на старые ядра
Но не в мейнлайне же бекпортировать в минорную версию. Можно понять, когда какой-то там ещё Android.
Потому как всех программистов учат давать понятные имена для констант, переменных и функций, а потом попадается в коде MSG_OOB и гадай то-ли это "out-of-band", то-ли "Oracle-old-bad".
Сишников — не учат. Это наверное деды из 50-х учат экономить байтики исходников. Сюда же бред про ширину кода 80 символов — "в монитор же не влазит!" Ага, в монитор 50-х годов.
Когда ж уже починят это use-after-free. Ну невозможно за всякими там флагами уследить и их реализациями. надо на корню решать
Оне не так уж часто и встречаются, а подавляющую часть времени софт просто работает.
> а подавляющую часть времени софт просто работает.Иногда просто и тихо портя пользовательские данные ...
Когда тебя починят? Вопрос из той же оперы.
Ничто не совершенно. А когда пишется индусами за пол зарплаты на удалёнке для корпоратов так вообще
Какой то отмазкой отдаёт. Индусам ничего не помешало же Windows 7-11(2) сделать, сравнительно стабильно. А, вам - в Линуксах всё индусы виноваты...
Скорей наблюдается(и по сути в Линуксе - вечно), отсутствие желания делать доброкачественно [в погоне за пиар плюшками вроде увеличения поддерживаемого оборудования [желая уничтожить этим их прямых конкурентов *BSD, как ранее все Unix]],
"Даром же! А, не хочешь пожизненно допиливать сам на корпорации даром же батрача - молча жри что дали!"
Какая же "неожиданная" "ошибка"
да ещё заказанная ораклом
>>Проблема проявляется начиная с ядра Linux 6.9 и устранена в обновлениях ядра Linux 6.1.143, 6.6.96, 6.12.36 и 6.15.5.мдя, как там поживает убунта LTS на EOL ядре 6.14 ?
Команда скриптологов решила пойти своим ядром...
- Почему XXXX не обрабатывается? Нам кажется что это неправильно.
- 10 лет назад просили сделать, с тех пор так и осталось.
> начиная с ядра Linux 6.9точно 6.9 ?
"I reviewed the implementation of MSG_OOB, and discovered a security bug (CVE-2025-38236) affecting Linux >=6.9 .....it was marked as fixing a bug introduced by the original MSG_OOB implementation, but luckily was actually only backported to Linux 6.9.8, so the buggy fix did not land in older LTS kernel branches""Fixed in these stable releases on 2025-07-06 (note that 6.12 and 6.15 are the only stable kernels where this actually has security impact):
6.1.143
6.6.96
6.12.36
6.15.5"
как хорошо что в 12 дебиане безопасно, а я такой лентяй на 13тый еще не обновился...
У тебя же прочего полно, из позже исправленного.
Какая же глупая маскировка бекдора. Линус как будто держит нас за дураков.
Тут дилемма. Либо Вы правы, либо он не контролирует ситуацию. Третьего не дано. Он вряд ли за второй вариант. Остается - Вы правы.
Как будто Линус знает все уязвимости в ядре, серьёзно?
Имплаешь что он не знает код своего собственного ядра? Так пойди и спроси его за сорцы
А мне вот интересно, почему никогда не называют имен тех кто данную CVE допустил?
Это не соответствует духу CoC.
а ещё и адрес проживания его и родственников, чтоб фанатики растолюбы приходили с ржавыми вилами, факелами, кричали доколе мы будем терпеть ваши юзе афтер фри и буфера оферфловы?
> кричали доколе мы будем терпеть ваши юзе афтер фри и буфера оферфловыА что им это сейчас мешает делать?
На самом деле чтобы "сообщество" знало своих героев.
Чтобы можно была их ставить в пример детям "Вот! Смотрите, это Настоящий™ Сишник! У него целых N лет 6ыdlокодинга на лучшем йазычке из 70х. Благодаря его бракоделию в ядре столько-то лет жила дыра. Хотите детки быть как он?"
У коммитов есть имена, было бы у кого желание их найти. Благо новому поколению это не грозит, они уже не знают как свойства открыть
Потому же, почему 6 августа не называют того, кто тогда допустил ту "CVE"
> Потому же, почему 6 августа не называют того, кто тогда допустил ту "CVE"А зачем? Их уже наградили N лет назад.
Сейчас их вспоминать уже не стоит, мавр дело сделал.
Судя по рогу изобилия их - главный мавр отлично себя чувствует. Его имя на Т. Мавр(ы) поменьше - тоже на месте. Ворон ворону глаз не выклюет. Рука руку моет.
Пограммировать некому будет?
Сишники опять не смогли в память?
Не то чтобы я был сильно удивлен... но не задумывались ли они что-то с этим делать?
А то 0-day дырища в ядре как-то совсем печально.
Сейчас опять будут сказки, что сишка - великолепный современный язычок, и больше ничего для счастья не нужно! Мол, код ядра линукса огромен - всё равно будут уязвимости, а сишка и ни при чём!
Все ждут вас - пока вы придёте и всё перепишете на ещё более великолепном и безопастном. Вообще всё.
Рекомендую тогда уж сразу на мега тормозе Java... Rust тут по безопасности языка опять мимо.
Хоть если даже на нём, даже без JIT, но оптимизируя ядро - переписать с нуля, подглядывая в это и делпя нормально,
- скорей всего всёравно выйдет с куда меньшими системными требованиями !
Потому что, такой вот ныне Линукс ядр - залагер.
Пусть и меньше 3-х GB винды 11 жрёт памяти (и то только за счёт конкуренции DE, а вот с ядром проблемка тут)
Чего? Ядро и минимальный субсет в фоне (OL10, минимальный инсталл) жрут порядка 400-500 метров. Современной винде такое близко не снилось (без UI).
Можно же взять более раннее
Ну нет, не современный, вернее не совсем - стандарт 23 версии добавляет, конечно, свежести языку, но называть сишку современным это чистой воды фанбойство.
Великолепный - да. Просто потому что позволяет эти самые переполнения и переиспользования. Вспомним тот же конкурс на обфускацию, где каждый год по истине ведиколепные победители.
Однако сам язык опасен, это как экспериментальное оружие, которое мало кому подвласно - в неумелых руках способно наделать делов.
> Великолепный - да.Как говори классик "кому и кобыла - невеста"))
> Просто потому что позволяет эти самые переполнения и переиспользования.
Гордиться кривостью инструмента? Ну такое.
Язык и стандарт абсолютно непродуманные, про что даже авторы языка писали.> Вспомним тот же конкурс на обфускацию, где каждый год по истине ведиколепные победители.
Примеры абсолютно неподдерживаемого овнокода.
По своей ценности на уровне "пермского конкурса кидания коровьих лепешек". Хотя последний возможно интереснее и полезнее)> Однако сам язык опасен, это как экспериментальное оружие,
Если бы это было так(((
Вон есть карбон, про который авторы честно пишут
Carbon Language is currently an experimental project.
И даже советуют:
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.А СИшка похожа на разрекламированную эскопету с кривым стволом, которая может стрелять в ногу. А от нее зависят человеческие жизни((
> которое мало кому подвласно - в неумелых руках способно наделать делов.
А у нас есть примеры умелых рук?
Почти каждую неделю у нас новости про CVE.
Супер квалифицированные прогеры типа Теодора Тцо совершают глупейшие ошибки и потом в ядре CVE живут годами.Но признать что просто инструмент кривой - вон шестерни торчат и наматывают пальцы, тут изоляции нету, поэтому по четным четвергам оно бьет током - никто не хочет.
Сейчас лед, слегка, тронулся, начали говорить про безопасность и бракоделов...
Но с их стороны копротивление максимальное.
Но, мы то все знаем что "танцору" мешает...
Сколько CVE в вашем коде?
А, да, у вас же нет кода...
По моему, это проблемы конкретно Google и Chrome. Их программисты налажали. Ядро Линукса тут не причём.
Почитать дальше первого абзаца вообще не можем, физически?