Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в подсистеме 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
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Аноним (2), 25-Сен-25, 22:19	+12 +/–
[bookworm] - linux <not-affected> (Vulnerable code not present) [bullseye] - linux <not-affected> (Vulnerable code not present) Вот вам и новое ядро.
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от Аноним (-), 25-Сен-25, 22:44	+/–
> отсутствием проверки существования объекта перед > выполнением операций с этим объектом. Оригинально. Хорошо что я себе -rc только что запилил, как раз с фиксом тематичным.
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от BUMP (?), 25-Сен-25, 22:59	+2 +/–
>> если страница недоступна, значит разработчики дистрибутива ещё не приступили к рассмотрению проблемы >> Уязвимость устранена в обновлениях ядра 6.16.4 и 6.12.44 Three-state logic
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

7. Сообщение от Аноним (7), 25-Сен-25, 23:02	+/–
Работа не волк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #38

8. Сообщение от Сосиска в кармане (?), 25-Сен-25, 23:09	+4 +/–
Ну и где эти ваши хвалёные статические анализаторы? Они должны были заметить, что у ресурса перед освобождением есть висящая ссылка.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #34, #62

9. Сообщение от Аноним (-), 25-Сен-25, 23:29    Скрыто ботом-модератором	+7 +/–
Ждём комментариев о том, что RAII - для слабаков, а у настоящих сишников ничего не висит.
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от Витюшка (?), 26-Сен-25, 00:23	+2 +/–
Статическими анализаторами: а) никто не пользуется (в реальном мире), даже те кто кричат как они любят С/С++ и эти самые анализаторы б) У них много ложных срабатываний, как ты там их не настраивай - через пару раз забиваешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #30, #72

13. Сообщение от Аноним (13), 26-Сен-25, 00:57	+/–
А в blame кто указан на этом файле? Из заметки звучит так, что механизм дефолтный, но наговнокодили и в прод.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #25, #41

15. Сообщение от penetrator (?), 26-Сен-25, 04:43	+/–
есть эксперты по контейнерам? если докер запускает вредоносный бинарь внутри контейнера, будет ли эксплуатация там отличаться от эксплуатации данной дыры на хосте?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #17, #24, #63

16. Сообщение от Аноним (-), 26-Сен-25, 05:00	+5 +/–
Нет, так как ядро используется это же. Можно заблокировать io_uring общесистемно через sysctl (ориентированные на безопасность дистрибутивы Linux часто так делают), через seccomp. Возможно, gVisor поможет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

17. Сообщение от Аноним (17), 26-Сен-25, 05:01	+3 +/–
Не эксперт, но сколь я понимаю, io_uring доступен в контейнере докера есть. https://github.com/containers/podman/issues/16796 Так что, скорее всего, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

21. Сообщение от User (??), 26-Сен-25, 08:23	–4 +/–
В смысле - этого тоже из "настоящих сишников"(ТМ) вычеркиваем и в jia tan'ы записываем, или что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #51

24. Сообщение от анонимз (?), 26-Сен-25, 09:14	+2 +/–
Все ядерные уязвимости валидны для докера, при учёте что прав у контейнерного процесса достаточно для обращения к уязвимой подсистеме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

25. Сообщение от Аноним (25), 26-Сен-25, 09:34	+/–
Его имя слишком известно, чтобы его называть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

26. Сообщение от Аноним (26), 26-Сен-25, 09:46	+/–
>устранена в обновлениях ядра 6.16.4 и 6.12.44 А предыдущие не затронуты? Не понял. Если да, то почему не написали в новости?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32

30. Сообщение от fu (?), 26-Сен-25, 10:53	+4 +/–
фстэка на вас нет. у нас весь код проверяется для сертификации
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #39, #42

32. Сообщение от Аноним (32), 26-Сен-25, 11:11	–1 +/–
Затронуты, похоже, но их пока только обновляют, вот уже сейчас только 5-я ветка не обновлена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

33. Сообщение от Аноним (33), 26-Сен-25, 11:26	+4 +/–
А всё потому, что нагородили своего io_uring апи, когда давно был проверенный в BSD kqueue. Но нет, в Линуксе надо обязательно сделать не как в BSD
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #70

34. Сообщение от Аноним (34), 26-Сен-25, 11:31	+1 +/–
Там всё немного сложнее, если посмотреть патч. Тут никакой анализатор не поможет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #71

37. Сообщение от tester (??), 26-Сен-25, 12:31	+/–
Вроде недавно дыра была уже в uring это типа дооптимизировались?!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

38. Сообщение от Аноним (-), 26-Сен-25, 13:02	–1 +/–
Конечно работа не волк. Работа это ворк. Если по теме "а я нифига не удивлен".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

39. Сообщение от Аноним (-), 26-Сен-25, 13:21	+4 +/–
> у нас весь код проверяется для сертификации Угу, проверяется. А потом такие же дыры как в мейнлайне))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

40. Сообщение от Аноним (40), 26-Сен-25, 13:23	–3 +/–
Эх, жаль, Android is not vulnerable. В 15 Android ядро 6.6. Может, в 16 завезут, но, скорее всего, уже с патчами.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #45

41. Сообщение от Аноним (41), 26-Сен-25, 13:32	+1 +/–
Изначально функцию io_futex_wait написал Jens Axboe. Тот самый что и пофиксил "проблему" через два года. Интересно, на сколько потолстел его банковский счет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #59, #64

42. Сообщение от Аноним (-), 26-Сен-25, 13:40	–2 +/–
> у нас весь код проверяется для сертификации Истинная правда. Вон недавной проверенный и сертифицированный ВыньХР ломанули. Но зато он был сертифицированный)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #46, #50, #61

43. Сообщение от Аноним (-), 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 из-за плачевного состояния безопасности      Мысль дня: Постоянство признак мастерства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

44. Сообщение от Аноним (44), 26-Сен-25, 13:58	+1 +/–
Там что-то использует io_uring? Он опциональный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

45. Сообщение от Анонимусс (?), 26-Сен-25, 14:00	+4 +/–
>  Эх, жаль, Android is not vulnerable. Из андроида выкинули io_uring еще в 2023 году. Так что он не будет уязвим ни в 15, ни в 16, ни далее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #48

46. Сообщение от fy (?), 26-Сен-25, 14:04	+1 +/–
когда там он депрекейтнулся? досихпор пользуетесь и ноете что его никто не исправляет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

47. Сообщение от Аноним (48), 26-Сен-25, 14:36	+/–
Как неожиданно! И опять уринг.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52

48. Сообщение от Аноним (48), 26-Сен-25, 15:05	+/–
> Из андроида выкинули io_uring еще в 2023 году вот есть же у кого-то здравый рассудок
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #49

49. Сообщение от Аноним (17), 26-Сен-25, 15:09	+3 +/–
Так а толку там с него? Им джава машину крутить, а не тот же postgress. Сам uring мб ок, просто что он дырявый. Ну тут фиксить надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

50. Сообщение от Аноним (50), 26-Сен-25, 15:47	+/–
Майкрософт показывал исходники для сертификации?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #55

51. Сообщение от Аноним (50), 26-Сен-25, 15:50	+/–
Житан это сигареты такие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #57

52. Сообщение от Аноним (52), 26-Сен-25, 16:20	+1 +/–
Но как же тысячи глаз и "базарное" программирование?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #53, #65

53. Сообщение от Аноним (53), 26-Сен-25, 16:42	+/–
> Но как же тысячи глаз и "базарное" программирование?! Ну тыщи глаз смотрели куда-то... Хотя я бы поставил не то, что случайности не случайны. И чул который сначала добавил код для бекдора, а потом героически его исправил, получил бочку варенья и ящик печенья как минимум, а как максиму повышение в звании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

55. Сообщение от танки онлайн (?), 26-Сен-25, 17:45	+/–
да
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #60

56. Сообщение от Аноним (56), 26-Сен-25, 18:34	+/–
А насколько io_uring поднимает производительность?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #66, #68, #69, #73

57. Сообщение от User (??), 26-Сен-25, 18:42	+/–
> Житан это сигареты такие. А Слава Кпсс - вообще не человек!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

59. Сообщение от Аноним (59), 26-Сен-25, 20:37	+1 +/–
На две годовых зарплаты за вычетом налогов и стоимости жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

60. Сообщение от Аноним (-), 26-Сен-25, 20:57    Скрыто ботом-модератором	+/–
И система воспроизводимых зборок у вантуза существует и ФСТЭК-у предоставлена?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

61. Сообщение от Аноним (61), 26-Сен-25, 21:19	+/–
Опять что-ли циферный со своими куплетами: "а вот там в Рэдмонде"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

62. Сообщение от Аноним (62), 26-Сен-25, 21:37	–1 +/–
Сишники ненавидят статические анализаторы, ибо они мешают г-кодить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

63. Сообщение от Аноним (62), 26-Сен-25, 22:14	+1 +/–
>если докер запускает вредоносный бинарь внутри контейнера, будет ли эксплуатация там отличаться от эксплуатации данной дыры на хосте? Зависит от уязвимости. При контейнеризации(это не только докер, но и systemd, bublewrap и так далее) можно ограничить доступные системные вызова, cappabilities, пользователей и так далее. Но, для каждой уязвимости нужно смотреть отдельно, так как во-первых она может быть доступна даже с этими ограничениями, а во-вторых в конкретном докер контейнере это может быть включено. Но формально разницы между приложением запущенным в контейнере и без него разницы нет, так как работают они с одним и тем же ядром.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

64. Сообщение от Аноним (13), 27-Сен-25, 00:45	+/–
Погуглил две секунды его. Жесть он олд, своё IO в ядре делал ещё в 2003 году, читай "Completely fair queueing (CFQ)", ядро было 2.5.60. Может реально маразм взял своё уже, и мейнтейнеры не вывозят всё это пухлое чудище проверять, куда интел пихает всякие nvme-over-ip и прочую дичь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

65. Сообщение от Аноним (13), 27-Сен-25, 00:50	–2 +/–
У тебя выбор - либо переплачивать за "готовое решение" без исходников ушлым мегакорпам, как только твоё закрытое решение станет невозможно вывозить в одну харю а покупать у тебя его никто не будет потому что ты не гугл, либо релизить своё решение как опенсорс и лицензировать его как-то, чтобы можно было с него бабки зарабатывать и клиент от твоей одной ленивой жопы не зависел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

66. Сообщение от Аноним (13), 27-Сен-25, 00:56	+1 +/–
В теории позволяет жонглировать между ядром и юзерспейсом одной и той же физической страницей памяти без доп проверок и копий, причём асинхронно. Прибавка при большом IO огромная по сравнению с записью в память, интераптом на syscall из юзерспейса, свитчем контекста, копией страниц из юзерспейса в другое место (потому что никто юзерспейсу не запрещал в эту память потом опять писать/читать начать) и только после этого юзерспейс может продолжить что-то делать. Тут же, насколько я понимаю, максимум что должно происходить - это segfault, потому что ты из юзерспейса попытался писать в страницу, которую уже подарил ядру, иди спрашивай ещё по новой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #67

67. Сообщение от Аноним (67), 28-Сен-25, 09:43	+2 +/–
Тесты на постгре показали ускорение в 2 раза при нагрузке в районе 1/4. При нагрузке близкой к 100 выйгрыша нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

68. Сообщение от Аноним (68), 28-Сен-25, 23:41	+/–
> насколько io_uring поднимает производительность? io_uring поднимает производительность троянов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

69. Сообщение от edo (ok), 29-Сен-25, 00:53	+1 +/–
он не только/не столько про поднятие производительности, сколько про нормальную асинхронность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

70. Сообщение от edo (ok), 29-Сен-25, 00:58	+/–
так, насколько я понимаю, уязвимости вызваны не недостатками io_uring, а в том, что к существующему коду приделывают асинхронные «ручки» из юзерспейса. замена на kqueue принципиально ситуацию не поменяла бы. а сама по себе идеия io_uring отличная же. не удивлюсь, если бсдшники её к себе затянут со временем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

71. Сообщение от ptr (ok), 29-Сен-25, 09:18	+/–
А как же MISRA-C 17.6?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #74

72. Сообщение от laindono (ok), 29-Сен-25, 17:17	+1 +/–
Вот по этому Rust и лучше крестов (к сишечке вопросов нет, она про другое). Ибо анализатор встроен в сам язык и нелья им не пользоваться. При этом сам дизайн сделан таким образом, что ложных срабатываний почти не существует. То есть ты конечно можешь добиться того же уровня качества кода в крестах. Но ты же не будешь заниматься этим всем ради какой-то одноразовой утилиты, верно? А тут придётся. Из этого выходит, что повышается среднее качество среднего когда. Суперкритические секции везде будут делаться вручную суперпрофессионалами с часовыми зарплатами, которые звучат как годовые. Но качество самой массовой части кода на самом деле гораздо важнее. По той причине, что улучшение на какие-то 0.5% в рамках всей индустрии намного важнее, чем 5000% в критической секции одного продукта. Эффект масштаба.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #78

73. Сообщение от Аноним (73), 29-Сен-25, 19:33	+/–
для работы с сетью полезно https://developers.redhat.com/articles/2023/04/12/why-you-sh...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

74. Сообщение от Аноним (34), 02-Окт-25, 11:06	+/–
Написать ядро операционной системы в рамках MISRA C? Удачи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #75

75. Сообщение от ptr (ok), 02-Окт-25, 20:10	+/–
> Написать ядро операционной системы в рамках MISRA C? Удачи. Я бы не сказал, чтобы всё было настолько плохо: https://ieeexplore.ieee.org/document/10716387 А с правилом 17.6, тем более: https://ieeexplore.ieee.org/mediastore/IEEE/content/media/62... Или Вы думаете что все перечисленные RTOS без ядра? )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #76

76. Сообщение от Аноним (34), 02-Окт-25, 23:23	+/–
ну такие "ОС", под ембедовку с заранее известными в compile time характеристиками, я и сам в таком стиле писал, там можно и вообще аллокатор не имплементить :) сравнили с пальцем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #77

77. Сообщение от ptr (ok), 03-Окт-25, 08:56	+/–
> ну такие "ОС" Почти полный список свободных RTOS. Чем они Вас не устраивают? > под ембедовку Если код под встраиваемые системы не ухудшился от соблюдения Misra C, то код под системы общего назначения тем более ничего не потеряет. Или Вы почему-то считаете иначе? > я и сам в таком стиле писал Дайте ссылку на GitHub, хотелось бы ознакомиться с Вашей RTOS. > сравнили с пальцем. Вот и сравним Вашу RTOS, например, с FreeRTOS )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

78. Сообщение от funny.falcon (?), 03-Окт-25, 10:49	+/–
Хоть я и не сподобился прогать на расте, но полностью согласен с вашим тезисом, и сам его часто приводил в дискуссиях: основная заслуга Rust  в том, что программист вынужден запускать статический анализатор при каждой компиляции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема