URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 137921
[ Назад ]
Исходное сообщение
"Уязвимость в подсистеме io_uring, позволяющая повысить привилегии в системе "
Отправлено opennews , 25-Сен-25 22:12 
В интерфейсе асинхронного ввода/вывода io_uring, предоставляемом ядром Linux, выявлена уязвимость (CVE-2025-39698), позволяющая непривилегированному пользователю добиться выполнения своего кода на уровне ядра. Уязвимость вызвана отсутствием проверки существования объекта перед выполнением операций с этим объектом. Проверить состояние новой версии пакета или подготовки исправления  в дистрибутивах можно на следующих страницах (если страница недоступна, значит разработчики дистрибутива ещё не приступили к рассмотрению проблемы): Debian, Ubuntu, Fedora, SUSE/openSUSE, RHEL, Gentoo и Arch...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=63946

Содержание
Сообщения в этом обсуждении
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 25-Сен-25 22:19 
[bookworm] - linux <not-affected> (Vulnerable code not present)
[bullseye] - linux <not-affected> (Vulnerable code not present)

Вот вам и новое ядро.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 25-Сен-25 22:44 
> отсутствием проверки существования объекта перед
> выполнением операций с этим объектом.

Оригинально. Хорошо что я себе -rc только что запилил, как раз с фиксом тематичным.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено BUMP , 25-Сен-25 22:59 
>> если страница недоступна, значит разработчики дистрибутива ещё не приступили к рассмотрению проблемы
>> Уязвимость устранена в обновлениях ядра 6.16.4 и 6.12.44

Three-state logic

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 25-Сен-25 23:02 
Работа не волк.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 13:02 
Конечно работа не волк.
Работа это ворк.

Если по теме "а я нифига не удивлен".

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Сосиска в кармане , 25-Сен-25 23:09 
Ну и где эти ваши хвалёные статические анализаторы? Они должны были заметить, что у ресурса перед освобождением есть висящая ссылка.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Витюшка , 26-Сен-25 00:23 
Статическими анализаторами:
а) никто не пользуется (в реальном мире), даже те кто кричат как они любят С/С++ и эти самые анализаторы
б) У них много ложных срабатываний, как ты там их не настраивай - через пару раз забиваешь
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено fu , 26-Сен-25 10:53 
фстэка на вас нет.
у нас весь код проверяется для сертификации
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 13:21 
> у нас весь код проверяется для сертификации

Угу, проверяется.
А потом такие же дыры как в мейнлайне))

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 13:40 
> у нас весь код проверяется для сертификации

Истинная правда.
Вон недавной проверенный и сертифицированный ВыньХР ломанули.
Но зато он был сертифицированный)))


"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено fy , 26-Сен-25 14:04 
когда там он депрекейтнулся? досихпор пользуетесь и ноете что его никто не исправляет?
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 15:47 
Майкрософт показывал исходники для сертификации?
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено танки онлайн , 26-Сен-25 17:45 
да
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 20:57 
И система воспроизводимых зборок у вантуза существует и ФСТЭК-у предоставлена?
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 21:19 
Опять что-ли циферный со своими куплетами: "а вот там в Рэдмонде"
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено laindono , 29-Сен-25 17:17 
Вот по этому Rust и лучше крестов (к сишечке вопросов нет, она про другое).

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

То есть ты конечно можешь добиться того же уровня качества кода в крестах. Но ты же не будешь заниматься этим всем ради какой-то одноразовой утилиты, верно? А тут придётся. Из этого выходит, что повышается среднее качество среднего когда. Суперкритические секции везде будут делаться вручную суперпрофессионалами с часовыми зарплатами, которые звучат как годовые. Но качество самой массовой части кода на самом деле гораздо важнее. По той причине, что улучшение на какие-то 0.5% в рамках всей индустрии намного важнее, чем 5000% в критической секции одного продукта. Эффект масштаба.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено funny.falcon , 03-Окт-25 10:49 
Хоть я и не сподобился прогать на расте, но полностью согласен с вашим тезисом, и сам его часто приводил в дискуссиях: основная заслуга Rust  в том, что программист вынужден запускать статический анализатор при каждой компиляции.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 11:31 
Там всё немного сложнее, если посмотреть патч. Тут никакой анализатор не поможет.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено ptr , 29-Сен-25 09:18 
А как же MISRA-C 17.6?
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 02-Окт-25 11:06 
Написать ядро операционной системы в рамках MISRA C? Удачи.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено ptr , 02-Окт-25 20:10 
> Написать ядро операционной системы в рамках MISRA C? Удачи.

Я бы не сказал, чтобы всё было настолько плохо: https://ieeexplore.ieee.org/document/10716387
А с правилом 17.6, тем более: https://ieeexplore.ieee.org/mediastore/IEEE/content/media/62...
Или Вы думаете что все перечисленные RTOS без ядра? )))

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 02-Окт-25 23:23 
ну такие "ОС", под ембедовку с заранее известными в compile time характеристиками, я и сам в таком стиле писал, там можно и вообще аллокатор не имплементить :)

сравнили с пальцем.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено ptr , 03-Окт-25 08:56 
> ну такие "ОС"

Почти полный список свободных RTOS. Чем они Вас не устраивают?

> под ембедовку

Если код под встраиваемые системы не ухудшился от соблюдения Misra C, то код под системы общего назначения тем более ничего не потеряет. Или Вы почему-то считаете иначе?

> я и сам в таком стиле писал

Дайте ссылку на GitHub, хотелось бы ознакомиться с Вашей RTOS.

> сравнили с пальцем.

Вот и сравним Вашу RTOS, например, с FreeRTOS )))


"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 21:37 
Сишники ненавидят статические анализаторы, ибо они мешают г-кодить.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 25-Сен-25 23:29 
Ждём комментариев о том, что RAII - для слабаков, а у настоящих сишников ничего не висит.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 00:57 
А в blame кто указан на этом файле? Из заметки звучит так, что механизм дефолтный, но наговнокодили и в прод.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено User , 26-Сен-25 08:23 
В смысле - этого тоже из "настоящих сишников"(ТМ) вычеркиваем и в jia tan'ы записываем, или что?
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 15:50 
Житан это сигареты такие.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено User , 26-Сен-25 18:42 
> Житан это сигареты такие.

А Слава Кпсс - вообще не человек!

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 09:34 
Его имя слишком известно, чтобы его называть
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 13:32 
Изначально функцию io_futex_wait написал Jens Axboe.
Тот самый что и пофиксил "проблему" через два года.
Интересно, на сколько потолстел его банковский счет?
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 20:37 
На две годовых зарплаты за вычетом налогов и стоимости жизни.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 27-Сен-25 00:45 
Погуглил две секунды его. Жесть он олд, своё IO в ядре делал ещё в 2003 году, читай "Completely fair queueing (CFQ)", ядро было 2.5.60. Может реально маразм взял своё уже, и мейнтейнеры не вывозят всё это пухлое чудище проверять, куда интел пихает всякие nvme-over-ip и прочую дичь.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено penetrator , 26-Сен-25 04:43 
есть эксперты по контейнерам?

если докер запускает вредоносный бинарь внутри контейнера, будет ли эксплуатация там отличаться от эксплуатации данной дыры на хосте?

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 05:00 
Нет, так как ядро используется это же. Можно заблокировать io_uring общесистемно через sysctl (ориентированные на безопасность дистрибутивы Linux часто так делают), через seccomp.

Возможно, gVisor поможет.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 05:01 
Не эксперт, но сколь я понимаю, io_uring доступен в контейнере докера есть.

https://github.com/containers/podman/issues/16796

Так что, скорее всего, да.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено анонимз , 26-Сен-25 09:14 
Все ядерные уязвимости валидны для докера, при учёте что прав у контейнерного процесса достаточно для обращения к уязвимой подсистеме.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 22:14 
>если докер запускает вредоносный бинарь внутри контейнера, будет ли эксплуатация там отличаться от эксплуатации данной дыры на хосте?

Зависит от уязвимости. При контейнеризации(это не только докер, но и systemd, bublewrap и так далее) можно ограничить доступные системные вызова, cappabilities, пользователей и так далее. Но, для каждой уязвимости нужно смотреть отдельно, так как во-первых она может быть доступна даже с этими ограничениями, а во-вторых в конкретном докер контейнере это может быть включено.

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

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 09:46 
>устранена в обновлениях ядра 6.16.4 и 6.12.44

А предыдущие не затронуты? Не понял. Если да, то почему не написали в новости?

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 11:11 
Затронуты, похоже, но их пока только обновляют, вот уже сейчас только 5-я ветка не обновлена.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 11:26 
А всё потому, что нагородили своего io_uring апи, когда давно был проверенный в BSD kqueue. Но нет, в Линуксе надо обязательно сделать не как в BSD
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено edo , 29-Сен-25 00:58 
так, насколько я понимаю, уязвимости вызваны не недостатками io_uring, а в том, что к существующему коду приделывают асинхронные «ручки» из юзерспейса. замена на kqueue принципиально ситуацию не поменяла бы.
а сама по себе идеия io_uring отличная же. не удивлюсь, если бсдшники её к себе затянут со временем.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено tester , 26-Сен-25 12:31 
Вроде недавно дыра была уже в uring это типа дооптимизировались?!
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 13:44 
> Вроде недавно дыра была уже в uring это типа дооптимизировались?!

Недавно?
Если посмотреть по тегам, то там дыра каждый год.
1 [26.09.2025] Уязвимость в подсистеме io_uring, позволяющая повысить привилегии в системе     
2 [25.04.2025] Прототип руткита для Linux, использующий io_uring для обхода анализаторов системных вызовов     
3 [01.04.2024] Уязвимость в подсистеме io_uring, позволяющая получить привилегии root     
6 [09.05.2023] Уязвимости в Netfilter и io_uring, позволяющие повысить свои привилегии в системе     
8 [24.11.2022] Уязвимость в подсистеме io_uring, приводящая к повышению привилегий     
9 [19.10.2022] Уязвимость в подсистеме io_uring ядра Linux, позволяющая повысить привилегии в системе     
10 [07.08.2022] Уязвимость в подсистеме io_uring ядра Linux, позволяющая получить права root из контейнера     
12 [19.09.2021] Уязвимость в подсистеме io_uring ядра Linux, позволяющая поднять свои привилегии

Поэтому гугловцы это шepeто выкинули из андроида.
[15.06.2023] Google отключил поддержку io_uring в ChromeOS и Android из-за плачевного состояния безопасности     

Мысль дня:
Постоянство признак мастерства.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 13:23 
Эх, жаль, Android is not vulnerable.

В 15 Android ядро 6.6.

Может, в 16 завезут, но, скорее всего, уже с патчами.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 13:58 
Там что-то использует io_uring? Он опциональный.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Анонимусс , 26-Сен-25 14:00 
>  Эх, жаль, Android is not vulnerable.

Из андроида выкинули io_uring еще в 2023 году.
Так что он не будет уязвим ни в 15, ни в 16, ни далее.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 15:05 
> Из андроида выкинули io_uring еще в 2023 году

вот есть же у кого-то здравый рассудок

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 15:09 
Так а толку там с него? Им джава машину крутить, а не тот же postgress.

Сам uring мб ок, просто что он дырявый. Ну тут фиксить надо.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 14:36 
Как неожиданно! И опять уринг.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 16:20 
Но как же тысячи глаз и "базарное" программирование?!
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 16:42 
> Но как же тысячи глаз и "базарное" программирование?!

Ну тыщи глаз смотрели куда-то...

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

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 27-Сен-25 00:50 
У тебя выбор - либо переплачивать за "готовое решение" без исходников ушлым мегакорпам, как только твоё закрытое решение станет невозможно вывозить в одну харю а покупать у тебя его никто не будет потому что ты не гугл, либо релизить своё решение как опенсорс и лицензировать его как-то, чтобы можно было с него бабки зарабатывать и клиент от твоей одной ленивой жопы не зависел.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 26-Сен-25 18:34 
А насколько io_uring поднимает производительность?
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 27-Сен-25 00:56 
В теории позволяет жонглировать между ядром и юзерспейсом одной и той же физической страницей памяти без доп проверок и копий, причём асинхронно. Прибавка при большом IO огромная по сравнению с записью в память, интераптом на syscall из юзерспейса, свитчем контекста, копией страниц из юзерспейса в другое место (потому что никто юзерспейсу не запрещал в эту память потом опять писать/читать начать) и только после этого юзерспейс может продолжить что-то делать. Тут же, насколько я понимаю, максимум что должно происходить - это segfault, потому что ты из юзерспейса попытался писать в страницу, которую уже подарил ядру, иди спрашивай ещё по новой.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 28-Сен-25 09:43 
Тесты на постгре показали ускорение в 2 раза при нагрузке в районе 1/4. При нагрузке близкой к 100 выйгрыша нет.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 28-Сен-25 23:41 
> насколько io_uring поднимает производительность?

io_uring поднимает производительность троянов.

"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено edo , 29-Сен-25 00:53 
он не только/не столько про поднятие производительности, сколько про нормальную асинхронность.
"Уязвимость в подсистеме io_uring, позволяющая повысить приви..."
Отправлено Аноним , 29-Сен-25 19:33 
для работы с сетью полезно
https://developers.redhat.com/articles/2023/04/12/why-you-sh...