| 1.2, Аноним (2), 22:19, 25/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +12 +/– |
[bookworm] - linux <not-affected> (Vulnerable code not present)
[bullseye] - linux <not-affected> (Vulnerable code not present)
Вот вам и новое ядро.
| | |
| 1.3, Аноним (-), 22:44, 25/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> отсутствием проверки существования объекта перед
> выполнением операций с этим объектом.
Оригинально. Хорошо что я себе -rc только что запилил, как раз с фиксом тематичным.
| | |
| 1.5, BUMP (?), 22:59, 25/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
>> если страница недоступна, значит разработчики дистрибутива ещё не приступили к рассмотрению проблемы
>> Уязвимость устранена в обновлениях ядра 6.16.4 и 6.12.44
Three-state logic
| | |
| |
| |
| 3.38, Аноним (-), 13:02, 26/09/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Конечно работа не волк.
Работа это ворк.
Если по теме "а я нифига не удивлен".
| | |
|
|
| 1.8, Сосиска в кармане (?), 23:09, 25/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Ну и где эти ваши хвалёные статические анализаторы? Они должны были заметить, что у ресурса перед освобождением есть висящая ссылка.
| | |
| |
| 2.12, Витюшка (?), 00:23, 26/09/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Статическими анализаторами:
а) никто не пользуется (в реальном мире), даже те кто кричат как они любят С/С++ и эти самые анализаторы
б) У них много ложных срабатываний, как ты там их не настраивай - через пару раз забиваешь
| | |
| |
| 3.30, fu (?), 10:53, 26/09/2025 [^] [^^] [^^^] [ответить]
| +4 +/– |
фстэка на вас нет.
у нас весь код проверяется для сертификации
| | |
| |
| 4.39, Аноним (-), 13:21, 26/09/2025 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> у нас весь код проверяется для сертификации
Угу, проверяется.
А потом такие же дыры как в мейнлайне))
| | |
| 4.42, Аноним (-), 13:40, 26/09/2025 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> у нас весь код проверяется для сертификации
Истинная правда.
Вон недавной проверенный и сертифицированный ВыньХР ломанули.
Но зато он был сертифицированный)))
| | |
| |
| 5.46, fy (?), 14:04, 26/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
когда там он депрекейтнулся? досихпор пользуетесь и ноете что его никто не исправляет?
| | |
| 5.61, Аноним (61), 21:19, 26/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Опять что-ли циферный со своими куплетами: "а вот там в Рэдмонде"
| | |
|
|
| 3.72, laindono (ok), 17:17, 29/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Вот по этому Rust и лучше крестов (к сишечке вопросов нет, она про другое).
Ибо анализатор встроен в сам язык и нелья им не пользоваться. При этом сам дизайн сделан таким образом, что ложных срабатываний почти не существует.
То есть ты конечно можешь добиться того же уровня качества кода в крестах. Но ты же не будешь заниматься этим всем ради какой-то одноразовой утилиты, верно? А тут придётся. Из этого выходит, что повышается среднее качество среднего когда. Суперкритические секции везде будут делаться вручную суперпрофессионалами с часовыми зарплатами, которые звучат как годовые. Но качество самой массовой части кода на самом деле гораздо важнее. По той причине, что улучшение на какие-то 0.5% в рамках всей индустрии намного важнее, чем 5000% в критической секции одного продукта. Эффект масштаба.
| | |
| |
| 4.78, funny.falcon (?), 10:49, 03/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
Хоть я и не сподобился прогать на расте, но полностью согласен с вашим тезисом, и сам его часто приводил в дискуссиях: основная заслуга Rust в том, что программист вынужден запускать статический анализатор при каждой компиляции.
| | |
|
|
| 2.34, Аноним (34), 11:31, 26/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Там всё немного сложнее, если посмотреть патч. Тут никакой анализатор не поможет.
| | |
| |
| |
| |
| |
| 6.76, Аноним (34), 23:23, 02/10/2025 [^] [^^] [^^^] [ответить]
| +/– | |
ну такие "ОС", под ембедовку с заранее известными в compile time характеристиками, я и сам в таком стиле писал, там можно и вообще аллокатор не имплементить :)
сравнили с пальцем.
| | |
| |
| 7.77, ptr (ok), 08:56, 03/10/2025 [^] [^^] [^^^] [ответить]
| +/– |
 > ну такие "ОС"
Почти полный список свободных RTOS. Чем они Вас не устраивают?
> под ембедовку
Если код под встраиваемые системы не ухудшился от соблюдения Misra C, то код под системы общего назначения тем более ничего не потеряет. Или Вы почему-то считаете иначе?
> я и сам в таком стиле писал
Дайте ссылку на GitHub, хотелось бы ознакомиться с Вашей RTOS.
> сравнили с пальцем.
Вот и сравним Вашу RTOS, например, с FreeRTOS )))
| | |
|
|
|
|
|
| 2.62, Аноним (62), 21:37, 26/09/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Сишники ненавидят статические анализаторы, ибо они мешают г-кодить.
| | |
|
| 1.13, Аноним (13), 00:57, 26/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А в blame кто указан на этом файле? Из заметки звучит так, что механизм дефолтный, но наговнокодили и в прод.
| | |
| |
| 2.21, User (??), 08:23, 26/09/2025 [^] [^^] [^^^] [ответить]
| –4 +/– |
В смысле - этого тоже из "настоящих сишников"(ТМ) вычеркиваем и в jia tan'ы записываем, или что?
| | |
| |
| |
| 4.57, User (??), 18:42, 26/09/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Житан это сигареты такие.
А Слава Кпсс - вообще не человек!
| | |
|
|
| 2.41, Аноним (41), 13:32, 26/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Изначально функцию io_futex_wait написал Jens Axboe.
Тот самый что и пофиксил "проблему" через два года.
Интересно, на сколько потолстел его банковский счет?
| | |
| |
| 3.59, Аноним (59), 20:37, 26/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
На две годовых зарплаты за вычетом налогов и стоимости жизни.
| | |
| 3.64, Аноним (13), 00:45, 27/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Погуглил две секунды его. Жесть он олд, своё IO в ядре делал ещё в 2003 году, читай "Completely fair queueing (CFQ)", ядро было 2.5.60. Может реально маразм взял своё уже, и мейнтейнеры не вывозят всё это пухлое чудище проверять, куда интел пихает всякие nvme-over-ip и прочую дичь.
| | |
|
|
| 1.15, penetrator (?), 04:43, 26/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
есть эксперты по контейнерам?
если докер запускает вредоносный бинарь внутри контейнера, будет ли эксплуатация там отличаться от эксплуатации данной дыры на хосте?
| | |
| |
| 2.16, Аноним (-), 05:00, 26/09/2025 [^] [^^] [^^^] [ответить]
| +5 +/– | |
Нет, так как ядро используется это же. Можно заблокировать io_uring общесистемно через sysctl (ориентированные на безопасность дистрибутивы Linux часто так делают), через seccomp.
Возможно, gVisor поможет.
| | |
| 2.24, анонимз (?), 09:14, 26/09/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Все ядерные уязвимости валидны для докера, при учёте что прав у контейнерного процесса достаточно для обращения к уязвимой подсистеме.
| | |
| 2.63, Аноним (62), 22:14, 26/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>если докер запускает вредоносный бинарь внутри контейнера, будет ли эксплуатация там отличаться от эксплуатации данной дыры на хосте?
Зависит от уязвимости. При контейнеризации(это не только докер, но и systemd, bublewrap и так далее) можно ограничить доступные системные вызова, cappabilities, пользователей и так далее. Но, для каждой уязвимости нужно смотреть отдельно, так как во-первых она может быть доступна даже с этими ограничениями, а во-вторых в конкретном докер контейнере это может быть включено.
Но формально разницы между приложением запущенным в контейнере и без него разницы нет, так как работают они с одним и тем же ядром.
| | |
|
| 1.26, Аноним (26), 09:46, 26/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>устранена в обновлениях ядра 6.16.4 и 6.12.44
А предыдущие не затронуты? Не понял. Если да, то почему не написали в новости?
| | |
| |
| 2.32, Аноним (32), 11:11, 26/09/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Затронуты, похоже, но их пока только обновляют, вот уже сейчас только 5-я ветка не обновлена.
| | |
|
| 1.33, Аноним (33), 11:26, 26/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
А всё потому, что нагородили своего io_uring апи, когда давно был проверенный в BSD kqueue. Но нет, в Линуксе надо обязательно сделать не как в BSD
| | |
| |
| 2.70, edo (ok), 00:58, 29/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
 так, насколько я понимаю, уязвимости вызваны не недостатками io_uring, а в том, что к существующему коду приделывают асинхронные «ручки» из юзерспейса. замена на kqueue принципиально ситуацию не поменяла бы.
а сама по себе идеия io_uring отличная же. не удивлюсь, если бсдшники её к себе затянут со временем.
| | |
|
| |
| 2.43, Аноним (-), 13:44, 26/09/2025 [^] [^^] [^^^] [ответить] | +/– | Недавно Если посмотреть по тегам, то там дыра каждый год 1 26 09 2025 Уязвим... большой текст свёрнут, показать | | |
|
| 1.40, Аноним (40), 13:23, 26/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– | |
Эх, жаль, Android is not vulnerable.
В 15 Android ядро 6.6.
Может, в 16 завезут, но, скорее всего, уже с патчами.
| | |
| |
| 2.45, Анонимусс (?), 14:00, 26/09/2025 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> Эх, жаль, Android is not vulnerable.
Из андроида выкинули io_uring еще в 2023 году.
Так что он не будет уязвим ни в 15, ни в 16, ни далее.
| | |
| |
| 3.48, Аноним (48), 15:05, 26/09/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Из андроида выкинули io_uring еще в 2023 году
вот есть же у кого-то здравый рассудок
| | |
| |
| 4.49, Аноним (17), 15:09, 26/09/2025 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Так а толку там с него? Им джава машину крутить, а не тот же postgress.
Сам uring мб ок, просто что он дырявый. Ну тут фиксить надо.
| | |
|
|
|
| |
| |
| 3.53, Аноним (53), 16:42, 26/09/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Но как же тысячи глаз и "базарное" программирование?!
Ну тыщи глаз смотрели куда-то...
Хотя я бы поставил не то, что случайности не случайны.
И чул который сначала добавил код для бекдора, а потом героически его исправил, получил бочку варенья и ящик печенья как минимум, а как максиму повышение в звании.
| | |
| 3.65, Аноним (13), 00:50, 27/09/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
У тебя выбор - либо переплачивать за "готовое решение" без исходников ушлым мегакорпам, как только твоё закрытое решение станет невозможно вывозить в одну харю а покупать у тебя его никто не будет потому что ты не гугл, либо релизить своё решение как опенсорс и лицензировать его как-то, чтобы можно было с него бабки зарабатывать и клиент от твоей одной ленивой жопы не зависел.
| | |
|
|
| |
| 2.66, Аноним (13), 00:56, 27/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
В теории позволяет жонглировать между ядром и юзерспейсом одной и той же физической страницей памяти без доп проверок и копий, причём асинхронно. Прибавка при большом IO огромная по сравнению с записью в память, интераптом на syscall из юзерспейса, свитчем контекста, копией страниц из юзерспейса в другое место (потому что никто юзерспейсу не запрещал в эту память потом опять писать/читать начать) и только после этого юзерспейс может продолжить что-то делать. Тут же, насколько я понимаю, максимум что должно происходить - это segfault, потому что ты из юзерспейса попытался писать в страницу, которую уже подарил ядру, иди спрашивай ещё по новой.
| | |
| |
| 3.67, Аноним (67), 09:43, 28/09/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Тесты на постгре показали ускорение в 2 раза при нагрузке в районе 1/4. При нагрузке близкой к 100 выйгрыша нет.
| | |
|
| 2.68, Аноним (68), 23:41, 28/09/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> насколько io_uring поднимает производительность?
io_uring поднимает производительность троянов.
| | |
| 2.69, edo (ok), 00:53, 29/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
он не только/не столько про поднятие производительности, сколько про нормальную асинхронность.
| | |
|
|
