URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 129045
[ Назад ]
Исходное сообщение
"Уязвимость в подсистеме io_uring, приводящая к повышению привилегий"
Отправлено opennews , 23-Ноя-22 19:07 
В реализации интерфейса асинхронного ввода/вывода io_uring, входящего в ядро Linux начиная с выпуска 5.1, выявлена уязвимость (CVE-2022-3910), позволяющая непривилегированному пользователю выполнить код с привилегиями ядра. Проблема проявляется в выпусках 5.18 и 5.19, и устранена в ветке 6.0...

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

Содержание
Сообщения в этом обсуждении
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Шарп , 23-Ноя-22 19:07 
>use-after-free

Rust.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Vlad , 23-Ноя-22 19:09 
Статические анализаторы
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Шарп , 23-Ноя-22 21:21 
Окстись. Какие статические анализаторы? Это же сишка, в которой ехал void* через void* видит в касте void*-void*. Никакой статический анализ тут не поможет.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 21:41 
Индусам за void* (именно void) ещё руки не обрубают? Вот гугл хорошую стратегию внедряет: на основе рейтинга худшие 10 тыс. вебмакак будут уволены.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 23:27 
Они тебя даже не примут, чтобы потом уволить. Ну и конечно ты должен быть особым ССЗБ, чтобы уехать в гулаг на инженерную должность.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено eganru , 24-Ноя-22 10:45 
Индусам за void* (именно void) ещё руки не обрубают? - у многих функций контракт предусматривает использование указателя на сырую память, в силу того, что на работу функции никак не влияет содержимое. Тот же memcpy, к примеру.

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

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 25-Ноя-22 00:11 
> их нанял эйчар, который заместо того чтобы выяснить уровень квалификации уточнял потратил лишний час на уточнение толерантны ли они к фрикам и педерастам

Казалось бы, такая халява — наплёл эйчару с три короба и стриги купоны на непыльной работёнке, левой пяткой пописывая CVE. Но эксперты с опеннета почему-то не осиливают даже это. То ли не всё так просто, то ли эксперты выходят тупее тех индусов.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Anonymus , 24-Ноя-22 09:51 
Это так как работает ассемблер. В чем проблема?
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Троллейбус , 24-Ноя-22 13:03 
А Раст выглядит как ассемблер.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 23:11 
> Окстись. Какие статические анализаторы? Это же сишка, в которой ехал void* через
> void* видит в касте void*-void*. Никакой статический анализ тут не поможет.

Хочу посмотерть что ты будешь с ioctl делать. Не, удалить это тебе таки не дадут, софт сломается :)

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 19:53 
Поступает хитро. На самом деле не освобождает память, а делает вид. Поэтому use-after-free нет, но течёт. ;)
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 20:22 
Симулирует освобождение памяти :)
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 20:44 
Симулирует переполнение памяти и зависание.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 21:59 
как насчёт нет
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 11:55 
Потом ещё после хруста учиться новые проблемы 20 лет солвить. Уж лучше бы голанге тащили
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Троллейбус , 24-Ноя-22 12:38 
И чем panic() отказ в обслуживании лучше? А еще без unsafe как быть?
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 19:16 
проблема ловится ещё при тестировании, а не едет к пользователям
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 19:12 
Какие значимые применения io_uring сегодня существуют или можно держать отключённым?
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено НяшМяш , 23-Ноя-22 19:24 
По-моему до сих пор ни один веб- или файловый сервер это не использует.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено uis , 05-Дек-22 13:52 
Nginx с самого начала
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 19:55 
Ещё с появления просто не успели применить.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено pin , 25-Ноя-22 11:20 
app-containers/lxc
app-emulation/qemu
sys-cluster/glusterfs
sys-block/fio
sys-apps/plocate
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Анонус , 23-Ноя-22 20:05 
Например
>Применение асинхронной буферизированной записи на базе io_uring до 80 раз снизило задержки в XFS
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 20:45 
> задержки в XFS

А если в других системах задержек нет, как в кособокой XFS?

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 22:01 
То, что в xfs считают задержками в других системах называют штатным режимом работы.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 23:31 
> А если в других системах задержек нет, как в кособокой XFS?

А ты попробуй что-то типа энтерпрайзных NVMe - тогда поймешь что им не нравилось. Там скорости такие что оно упирается в оверхед ядра.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 05:02 
> энтерпрайзных NVMe

я в курсе, что тут каждый второй таскал трансконтинентальный плуг.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 21:16 
Достаточно даже просто компильнуть ядро линукса, там и нагрузки проца и IO хватает. При том если тому NVME под стать и проц нормальный взять, типа новых амд, можно проникнуться перфомансом так то.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Анонус , 24-Ноя-22 11:39 
>> задержки в XFS
> А если в других системах задержек нет, как в кособокой XFS?

Не бывает здоровых - бывают недообследованные.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено edo , 25-Ноя-22 22:53 
> Применение асинхронной буферизированной записи на базе io_uring до 80 раз снизило задержки в XFS

Это формулировка кривая, речь про ускорение приложений, использующих io_uring

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 21:59 
Scylla вроде уже умеет работать через io_uring
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 19:23 
> связанному с некорректным обновлением счётчика ссылок

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

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Ivan_83 , 23-Ноя-22 19:42 
Учитывая что это не первый и не второй баг в этом модуле то видимо там проблема с дизайном/архитектурой.
Раст не поможет написать хороший код.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено пох. , 23-Ноя-22 21:03 
Раст прекрасно поможет не написать плохого. Нет кода, нет проблемы.

Те у кого проблемы с архитектурой а на деле в счетчике запутались - просто никогда не удовлетворят borrow checker и оно у них не соберется. А если соберется- безопастно упадет по panic и снова все в полном порядке и никому вреда от этого нет.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено yet another anonymous , 24-Ноя-22 00:25 
> Раст прекрасно поможет не написать плохого.

Это врядли (C).

> Нет кода, нет проблемы.

Хотя, да, резонно.

> Те у кого проблемы с архитектурой а на деле в счетчике запутались - просто никогда не удовлетворят borrow checker...

Толпы индусов после прослушивания воодушевляющих курсов и не то забороть могут. Хотя что индусы --- тут вот шедевры от татарина мегабайтами сыпятся... Б...ь. Короче, _хипстерский код_ от эффективных, команндно-ориенированных социально раскрепощённых архитекторов/кодировщиков, нацеленных на результат --- НЕ ИМЕЕТ НАЦИОНАЛЬНОСТИ.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено edo , 25-Ноя-22 22:59 
> Учитывая что это не первый и не второй баг в этом модуле
> то видимо там проблема с дизайном/архитектурой.

Идея-то хорошая, просто интеграция этого в существующее ядро — это тот ещё квест. Как и неймспейсы, например.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 19:55 
Ты так говоришь как будто раст в чём-то хорош.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 12:03 
Пока единственная вменяемая утилита которая на нём нашлась - ripgrep... и то только потому что под фортки нужен был "нативный" единый бинарь
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Анонн , 25-Ноя-22 17:03 
А как же resvg? Они собой заменила предыдущую либу (уже не помню какую, librsvg вроде бы)
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 19:40 
> Уязвимость вызвана обращением к уже освобождённому блоку памяти (use-after-free)

Проверки указателей замедляют программы! Что-то такое, видимо, думают программисты, пишущие на C :}

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 20:11 
ну, когда пишешь на любом языке, каждый if вызывает в душе вопрос, а нужен ли здесь этот if, и неважно, к чему он относится, к указателям или к "бизнес-логике". В высокоуровневых языках ты не имеешь контроля над указателями, ифы для них не пишешь и про них вообще не думаешь, за тебя уже подумали. А на си тебя заставляют думать над указателями, так что, вводя новый if, задаешься вопросом, а нужен ли он конкретно здесь, быть может конкретно здесь указатель уже подразумевается корректный и не-нулл? У меня всё, всем спасибо за внимание.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено YetAnotherOnanym , 23-Ноя-22 21:30 
Передвигаясь по пересечённой местности, смотреть и выбирать, куда наступаешь - это слишком сложно. Проще и быстрее зажмуриться и бежать так быстро, как только можно.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 21:18 
Видишь ли, в зависимости от ситуации иногда и так приходится. Если за тобой чешут несколько злобных, а может еще и вооруженных типов, ты врядли будешь наслаждаться пейзажами.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 22:08 
Нет, проще на транспортном средстве с воздушной подушкой (раст) там проехать и вертеть головой, выискивая уже глубокие овраги, а не мелкие кочки и трещинки, где ты пешком рано или поздно ноги сломаешь, как бы ни смотрел и выбирал, куда наступаешь
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 20:01 
В дебиан тестинг давно 6.0
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 20:47 
> Проблема проявляется в выпусках 5.18 и 5.19, и устранена в ветке 6.0

А что, патчи для 5.* нельзя сделать по религиозным соображениям?

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Golangdev , 23-Ноя-22 20:59 
> Ubuntu

Корень проблем, дистрибутив с пакетами, стабильно отстающими на 2-3 года.

Используйте Fedora, там софт/ядро свежее.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 21:01 
у меня в дебиане-9 еще 4.9, а в 11ом 5.10...

вот что значит стабилен как скала!

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено anonima , 24-Ноя-22 09:03 
Версия KDE:  3.5.5
  Пользователь:  user
  Имя узла:  debian
  Система:  Linux
  Ядро:  2.6.18-6-vserver-686
  Процессор:  i686
  Используйте вкладку "Поиск", если вы не уверены, где именно искать нужный параметр.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено uis , 05-Дек-22 13:57 
Стабилен как Scala
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено YetAnotherOnanym , 23-Ноя-22 21:20 
Ну и что, что урина дырявая. Зато быстрая-пребыстрая.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 21:25 
Опять корпорастическая поделка отличилась.
Все эти нужные 1.5 применениям счастья надо выкидывать в модули и по умолчанию делить на 0.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 23:32 
Скоростной IO с низким оверхедом имеет чуть более 1.5 применений.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 05:05 
> чуть более 1.5 применений

1.5(0)1
Что такое "в периоде", наверно, тебе не надо объяснять?

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 21:57 
Шутки шутками, а диды действительно более качественный код писали. БОльшая часть уязвимостей, в новостях последних месяцев, начинаются с версии ядра 5.*. Видимо студенты за чашку риса от корпораций писали.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 22:07 
Да это просто тысячи глаз дидов уже слепые все, пропускают написанное ненастоящими сишниками. Раньше-то о-го-го! Хотя нет, погодите, в сях use-after-free уже 50 лет ловят, всё никак не научатся.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 22:35 
Есть код - есть баги.
Нет кода - нет багов.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 22:10 
но баги-то разные и 70% из них можно было бы избежать
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 03:45 
Диды пять тысяч строк юникса (для одной-единственной архитектуры) написали, тогда можно было распечатку вечером за чашечкой кофе изучить.
Это плата за сложность.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Вы забыли заполнить поле Name , 23-Ноя-22 22:16 
Есть ощущение, что такие новости в последнее время специально пишутся, чтобы сформировать у неопытных нужное кому-то мнение про небезопасность сами знаете чего и замену его на сами знаете что, а там и вендор лок и прочие прелести.

У кого-то есть реальная статистика изменения кол-ва уязвимостей в ядре за  
Последнее время?

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 23-Ноя-22 22:26 
Новости лишь отражают те баги, которые выявляют (по статистике Google 70% уязвимостей вызваны некорректной работой с памятью). Вы ещё скажите, что уязвимости в ядро специально добавляют чтобы дискредитировать Си.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Вы забыли заполнить поле Name , 24-Ноя-22 00:12 
> Новости лишь отражают те баги, которые выявляют (по статистике Google 70% уязвимостей
> вызваны некорректной работой с памятью). Вы ещё скажите, что уязвимости в
> ядро специально добавляют чтобы дискредитировать Си.

Уходишь от ответа, приводишь левую статистику. Давай статистику по кол-ву уязвимостей в ядре по времени.


"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 12:12 
Давай статистику по количеству уязвимостей в ядре на других языках на 100000 строк кода) А то как-то нечестно сравнивать то, что есть и отлично работает, с пшиком
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Троллейбус , 24-Ноя-22 13:01 
У Гугла есть уже Го -- и он приятнее выглядит гораздо, чем Раст. А проверять параметры и буферы надо обязательно. И прочие знаковые и беззнаковые типы.
Из-за семантики и синтаксиса Раста даже если не будет ошибок с памятью, то будут проблемы внимательности и опечаток, ошибок в условиях и операторах сравнения.
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено yet another anonymous , 24-Ноя-22 00:15 
> У кого-то есть реальная статистика изменения кол-ва уязвимостей в ядре за Последнее время?

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

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено лютый ж.... , 24-Ноя-22 08:00 
>У кого-то есть реальная статистика изменения кол-ва уязвимостей в ядре за Последнее время

лень этим заниматься, но могу сказать что подавляющая часть недавних дырок (и в ядре и в openssl) неактуальна для например centos7 или oracle linux 8. не юзай убунту и всё будет гуд. а на десктопе пофиг, наоборот чем новее, тем лучше (void, arch, gentoo)

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Анонн , 25-Ноя-22 10:53 
О, любители теории заговоров пожаловали.
А может это растовики прокрались и н̶а̶д̶е̶л̶а̶л̶и̶ ̶с̶и̶ш̶н̶и̶к̶а̶м̶ ̶в̶ ̶ш̶т̶а̶н̶и̶ш̶к̶и̶  понаписывали багов в ядро?
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Троллейбус , 25-Ноя-22 14:09 
Если твое мировоззрение ограничено, это не значит, что ты все знаешь о мире так, как считаешь
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 25-Ноя-22 13:57 
Большинство  всплывающих последнее время дыр, как правило, касаются новомодных систем, добавленных относительно недавно, таких как BPF, nftables и io_uring. Плюс огромный пласт уязвимостей, которые раньше воспринимались как безобидные ошибки и могли быть эксплуатированы только root-ом, но после появления user namespace всё изменилось и для атаки теперь стало достаточно виртуального root в отдельном пространстве имён.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 25-Ноя-22 14:35 
А может просто нашелся смелый человек, который решил рассказать всем ПРАВДУ про эту багованную подстилку корпорастов?
Про АНБ, которые туда напихивают туда бэкдоров использую д̶р̶е̶в̶н̶е̶е̶ ̶г̶о̶в̶н̶о̶ ̶м̶а̶м̶о̶н̶т̶а̶  божественный язык си, пользуясь тем, что всегда можно съехать "ну, это просто очередная бажина с памятью, таких у нас куча, расходитесь граждане, тут нет ничего интересного"?
И хоть как-то пытается противостоять их пропаганде "Линух надежный! Разворачивай на своем серваке! s/Наши/Ваши/ данные будут в безопасности! Не нужна вам никакая BSD"
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Вы забыли заполнить поле Name , 26-Ноя-22 02:59 
> Про АНБ, которые туда напихивают туда бэкдоров использую д̶р̶е̶в̶н̶е̶е̶ ̶г̶о̶в̶н̶о̶ ̶м̶а̶м̶о̶н̶т̶а̶  божественный язык си, пользуясь тем, что всегда можно съехать "ну, это просто очередная бажина с памятью, таких у нас куча, расходитесь граждане, тут нет ничего интересного"?

АНБ (внезапно) С более не рекомендует: https://www.opennet.dev/opennews/art.shtml?num=58111 А вот язчок, который завязан на одного поставщика, генерит фиг пойми что - это ок. Гораздо ведь проще договориться с кем-то одним. А напихать бэкдор можно куда угодно.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 26-Ноя-22 12:23 
> АНБ (внезапно) С более не рекомендует

Потому что это (внезапно) хитрый план. Посмотри какой "спор" был в той теме и сколько людей сказало "о, раз анб не рекомендует, то буду писать на своей сишечке до скончания времен!"
А это не только не опеньке так. На реддите, хабре, даже в твиттере (какие-то неадекваты) написали что мол "это заявление доказательство что во всех рекомендуемых языках есть закладки!"
И хитрый анбшник уже потирает свои ручонки "Пишите на сишечке, облегчайте мне работу".

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

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Вы забыли заполнить поле Name , 27-Ноя-22 04:07 
> Попробуй напихать бекдор в софт на хаскеле. Тебе на первом же ревью спросят "что за фигня?"

Бэкдор будет в самом компиляторе.

"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено лютый ж.... , 24-Ноя-22 07:57 
интересно как там unbreakable оракель-линукс c 5.4, вляпался или на самом деле неломаха?
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено Аноним , 24-Ноя-22 19:51 
Ничего нового. Чем больше система, которая разрабатывается с помощью инструмента, безопасность которого зависит исключительно от человеческого фактора (квалификация, внимательность), тем больше zero-day дыр в каждой новой фиче. Сишка хороша для микроконтроллеров, выполняющих строго одну задачу, которую нужно впихнуть в драконовские ограничения по памяти. Но не для тридцатилетнего ядра циклопических размеров
"Уязвимость в подсистеме io_uring, приводящая к повышению при..."
Отправлено egan , 24-Ноя-22 22:07 
В микроконтроллерах тоже самое, что и везде - куча задач, потоков и.т.д. Только еще и с ресурсами плохо все.