The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в подсистеме io_uring, позволяющая получить привилегии root

01.04.2024 10:10

В интерфейсе асинхронного ввода/вывода io_uring, предоставляемом ядром Linux, выявлена уязвимость (CVE-2024-0582), позволяющая непривилегированному пользователю получить права root в системе. Для эксплуатации уязвимости достаточно обычного локального доступа к системе, без необходимости манипуляций с пространствами имён. В настоящее время публично доступен работающий эксплоит, а также подробно описана вторая техника эксплуатации уязвимости.

Уязвимость вызвана обращением к уже освобождённому блоку памяти (use-after-free) в подсистеме io_uring, возникающем при регистрации и освобождении кольцевого буфера, созданного с флагом IORING_REGISTER_PBUF_RING. В ситуации применения к буферу операции mmap(), он остаётся отражённым в пространство пользователя после выполнения операции его освобождения (IORING_UNREGISTER_PBUF_RING). Используя данную особенность, атакующий может читать и записывать данных в страницы памяти, возвращённые системе распределения памяти ядра.

Проблема проявляется начиная с выпуска ядра Linux 6.4 и устранена в выпусках 6.7 и 6.6.5, а также в пакете с ядром 6.5.0-21, подготовленным для Ubuntu 22.04 и 23.10. Примечательно, что в основном ядре проблема была исправлена в декабре 2023 года, проект Google Zero открыл доступ к сигнализирующему о наличии уязвимости сообщению об ошибке 8 января, а пакет с исправленным ядром 6.5 для Ubuntu был сформирован лишь 22 февраля 2024 года. В других дистрибутивах проследить за исправлением и подверженностью уязвимости можно на страницах: Debian, Gentoo, RHEL, SUSE, Fedora, Arch.

Первый эксплоит манипулирует созданием большого числа контролируемых атакующим страниц памяти для определения раскладки памяти в ядре и доступа к соседним физическим страницам памяти, используя в качестве маяков содержимое определённым образом заполненных структур сетевых сокетов. Для запуска кода в эксплоите задействован "гаджет" (последовательность существующих в ядре инструкций), приводящий к выполнению функции call_usermodehelper_exec, предназначенной для запуска процессов в пространстве пользователя из ядра.

Второй эксплоит основывается на том, что при исчерпании всех slab-блоков в кэше (например, при открытии файла много раз) свободные страницы памяти, к которым остаётся доступ атакующего, используются системой распределения памяти для создания нового slab-блока и все новые файловые структуры начинают размещаться в этом блоке. Соответственно, какие-то файловые структуры попадут в страницы памяти, которые может читать и записывать атакующий. Эксплуатация при этом сводится к организации попадания в файловый кэш нужного файла и замене в связанных с ним файловых структурах поля f_mode, определяющего права доступа, что позволяет сделать доступным на запись нужный системный файл, например, /etc/passwd.

  1. Главная ссылка к новости (https://blog.exodusintel.com/2...)
  2. OpenNews: Google отключил поддержку io_uring в ChromeOS и Android из-за плачевного состояния безопасности
  3. OpenNews: Уязвимость в подсистеме io_uring ядра Linux, позволяющая получить права root из контейнера
  4. OpenNews: Уязвимости в Netfilter и io_uring, позволяющие повысить свои привилегии в системе
  5. OpenNews: Уязвимость в подсистеме io_uring, приводящая к повышению привилегий
  6. OpenNews: Уязвимость в подсистеме io_uring ядра Linux, позволяющая повысить привилегии в системе
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60891-io_uring
Ключевые слова: io_uring, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (123) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Bklrexte (ok), 11:23, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Немного не понимаю, почему с io_uring так много уязвимостей.
     
     
  • 2.11, Аноним (11), 11:50, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как я слышал, это от того, что ядро не разрабатывалось поддерживать такие вещи, и пихают невпиху3мое. А на модернизацию уйдёт ещё не одно десятилетие.
     
  • 2.18, Аноним (18), 12:15, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • –17 +/
    > use-after-free

    Дело скорее в языке, чем в самом io_uring (но надо признать, что автор эпично прошел по всем граблям сишечки).

     
     
  • 3.21, Аноним (21), 12:34, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ага ага
    https://github.com/Speykious/cve-rs
     
     
  • 4.25, Аноним (-), 12:44, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    К чему твой висер типа "а у вас негров линчуют"?
    Тред для растохейта на две тамы выше, дружок-пирожок.

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

     
     
  • 5.54, Стив Балмер (?), 14:59, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    так гугл как и мягкие это часть тысячеглаза, ты что не знал ? у них же куча продуктов на линь завязана, вот и стараются
     
     
  • 6.102, Минона (ok), 22:59, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, Стиви, Гугл и Ко это другого типа "тыщиглаз", эти смотрят в код и видят баги, а те другие "тыщиглаз" смотрят в код а видят фигу.
     
     
  • 7.110, Стив Балмер (?), 10:29, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    да не, вырви уже из себя это раболепие, тысячеглаз это уже давно не тока отшельники в замызганных свитерах, это также и галстучники работающие на разные компании. Проблемы в коде замечают и те и другие, но твой ум зачем-то акцентирует внимание тока на вторых выделяя их в особую касту.
     
     
  • 8.111, Аноним (-), 10:55, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, вроде зачечают и те, и те, но почему-то заметил чел из майкрософта ... текст свёрнут, показать
     
     
  • 9.114, Аноним (-), 11:56, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так ведь заметил ... текст свёрнут, показать
     
  • 9.135, Стив Балмер (?), 17:15, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    чел из крупной ИТ компании бесплатно поработал тысячеглазом на общее дело, чес... текст свёрнут, показать
     
  • 6.149, aname (?), 13:23, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ЧСХ, из тысячеглаза, только одна пара нашла лютейший ад, который готовился в liblzma.

    Так и живём

     
  • 5.55, Аноним (55), 15:06, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тот же гугл не стал завозить Rust в Chrome, а решил свои проблемы с безопасностью памяти активным использованием санитайзеров включая MiraclePtr. Так что да, они делают опенсорс лучше.
     
     
  • 6.68, Анонин (-), 15:54, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Тот же гугл не стал завозить Rust в Chrome

    Точно не стал?
    А то тут chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/rust.md#Rust-in-Chromium какие-то чуваки пишут:

    "The Rust toolchain is enabled for and supports all platforms and development environments that are supported by the Chromium project. The first milestone to include full production-ready support was M119.

    Rust is approved by Chrome ATLs for production use in certain third-party scenarios."

    MiraclePtr себя не оправдал. Там улучшение ~57% при значительном потреблении ресурсов.
    https://www.opennet.ru/opennews/art.shtml?num=60482

     
  • 4.28, Аноним (28), 12:53, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Ага ага
    > https://github.com/Speykious/cve-rs

    Ну давай посмотрим, че там:
    [CODE]
    pub fn segfault() -> ! {
           let null = crate::null_mut::<u8>();
            *null = 42;
    [/CODE]
    Смотрим, че эт за самописный null_mute:
    [CODE]
    /// Equivalent to ['std::ptr::null()'], but returns a null reference instead.
    pub fn null<'a, T: 'static>() -> &'a T {
            crate::transmute(0usize)
    }
    [/CODE]
    далее оно уходит в велосипедно-обфусцированный transmute, в общем раз "equivalent", то заменяем на оригинал:
    [CODE]
    +++ b/src/segfault.rs
    @@ -7,7 +7,7 @@
    ///
    /// See ['crate::transmute()']
    pub fn segfault() -> ! {
    -       let null = crate::null_mut::<u8>();
    +       let null = std::ptr::null_mut::<u8>();
            *null = 42;
    [/CODE]
    и вуаля:
    [CODE]
    cargo build
       Compiling cve-rs v0.6.0 (/tmp-build/seg/cve-rs)
    error[E0133]: dereference of raw pointer is unsafe and requires unsafe function or block
      --> src/segfault.rs:11:2
       |
    11 |     *null = 42;
       |     ^^^^^^^^^^ dereference of raw pointer
       |
       = note: raw pointers may be null, dangling or unaligned; they can violate aliasing rules and cause data races: all of these are undefined behavior

    For more information about this error, try 'rustc --explain E0133'.
    error: could not compile 'cve-rs' (lib) due to previous error
    [/CODE]
    В общем, опеннетный Военов Супротив Раста опять развели, как кроликов ...

    Главное, повторять почаще.


     
     
  • 5.76, Аноним (76), 17:03, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну что-то вроде того ироничного репозитория с хэллоу ворлдом на расте на тысячи строк, собирающийся 5 часов.

    Не видел чтобы кто-то делал такое же на си, но думаю 5 часами компиляции они не отделались бы.

     
     
  • 6.134, Аноним (134), 16:28, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не видел чтобы кто-то делал такое же на си

    Правильно. Потому что программисты на Си работают.

     
  • 6.148, 12yoexpert (ok), 13:10, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    где-то проводили конкурск на самый короткий и долгокомпилирующийся код на си. там чел каким-то кривым include-ом отправил компилятор на вечную компиляцию
     
  • 4.41, Аноним (18), 14:10, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Эпичный тред, в котором это пытаются заставить работать - https://github.com/Speykious/cve-rs/issues/4

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

     
  • 4.45, Анонин (-), 14:24, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ой, да ладно вам гнать на этот проект.
    Он и аналогичные очень полезны! Благодаря им можно найти в расте soundness и исправить.
    Потому что бездумно верить что багов нет - просто преступление.
    Так что пусть чуваки развлекаются разными извращениями и в итоге делают раст еще лучше и надежнее.
     
  • 4.143, namenotfound (?), 03:00, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    я вообще не врубаюсь что это доказывает

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

    это как ткнуть в баг в gcc или clang и сказать, что это весь си неправильный

     
  • 3.108, adolfus (ok), 09:41, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Агент Байдена? Работаешь в команде дискредитации C и C++?
     
  • 2.22, Аноним (22), 12:34, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Мне кажется система io_ring немного переусложнена там слишком много флагов, опций и режимов. Им нужно было начинать как-то попроще с минимум опций, а когда уже точно протестировано хорошо добавлять свои опции понемногу. Ну и сама конструкция с  shared memory и кольцевыми буферами в ней не совсем уж простая в реализации.
     
     
  • 3.57, Аноним (-), 15:22, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не, не сработает.
    Сразу начнется вой и нытье, что 'именно это флажок мне нужен', 'добавьте немедленно', 'работало, а вы все сломали', 'вы мне обязаны, 'я вашим ио-рингом пользуюсь'

    Уже такое проходили с вейландом, когда с нуля начали создавать и реализовывать протоколы, так  фанаты иксов ноют до сих пор.

     
     
  • 4.105, Аноним (105), 01:13, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так может не надо с нуля переписывать то, что уже работает и чем люди пользуются? Говно же каждый раз выходит.
     
     
  • 5.126, Василий (??), 14:53, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну так может не надо с нуля переписывать то, что уже работает и чем люди пользуются? Говно же каждый раз выходит.

    Это же ты про X windows system  написал, который переписывали и форкали за его историю множество раз?. И всё равно дырявое получилось как ни старались.

     
  • 2.65, Аноним (65), 15:42, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    По той же причине, что и в BPF, nftables. Не отловили ещё всех багов.
     
  • 2.87, vitalif (ok), 18:25, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Асинхронщина. А ядро хронически писали как синхронное тредовое г**но. Вылезают проблемы синхронизации :-)
     
     
  • 3.104, 1апреля (?), 00:47, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А как надёжно отладить все возможные ситуации в асинхронке? Это не F5 в браузере нажать
     

  • 1.4, Аноним (4), 11:28, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Автора этого поделия давно пора взять на карандаш: не первая его уязвимость и что-то мне подсказывает, что не последняя.
     
     
  • 2.12, Аноним (-), 11:51, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Можешь автора этого поделия брать хоть за карандаш, хоть за что угодно.
    А толку, все равно у тебя нет замены для этой лабуды.
    Конечно ты мог бы взять и написать свой вариант асинк И/О, и я думаю, что у тебя бы получилось без ошибок, но это не точно)

    Гугл, который собственно и нашел уязвимость, пишет что
    60% of the submissions exploited the io_uring component of the Linux kernel
    https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html

    Возможно поэтому они эту лажу отключили и в андроиде, и в хромоси.
    А лапчатые пусть сидят на бекдорах)

     
  • 2.24, Аноним (22), 12:38, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Просто он как-то переусложнил всё, там миллион разных флагов, поэтому и уязвимости сыпятся.
     
  • 2.30, Аноним (22), 13:10, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В любом случае если его правильно реализовать это выходит самый эфиктивный способ i/o общения с ядром.
     
     
  • 3.38, Аноним (38), 13:41, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Действительно, надо всего лишь правильно реализовать
     
  • 2.44, iPony129412 (?), 14:18, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А кто останется?
     

  • 1.5, Аноним (11), 11:29, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наверное, имеет смысл отключать сабж, вроде нигде кроме qemu и не используется (хотя ускорение обещают приятное в теории). Лично я давно отключил -- если я не использую, никакого смысла держать этот бэкдор ядре. Ну а кто там дистрибутивные ядра со всеми бэкдорами использует, тем только страдать.
     
     
  • 2.7, Аноним (11), 11:36, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Правда, в libuv собирались добавить, и вот это поделие ускорить бы неплохо.
     
  • 2.101, vitalif (ok), 22:46, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Я в витасторе юзаю))
     

  • 1.6, Аноним (-), 11:36, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Сначала подумал, что это шутка, ведь сегодня День Дурака.
    А потом решил, это же use-after-free и получение рута, и с таким не шутят)

    В общем классическая уязвимость "позволяющая непривилегированному пользователю получить права root в системе" да еще и с рабочим эксплойтом.
    Хорошо, что это совсем-словсем не связанно с используемым языком, и возможностями по отстрела ног которые он дает.

     
     
  • 2.19, Аноним (19), 12:17, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да господи, язык тот тут причем?
    Если программист не хочет или не может банально обнулить указатель после освобождения памяти, то увы, вина того, кто пишет
     
     
  • 3.23, Аноним (-), 12:35, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хм, а я что сказал что "виноват язык"?
    Понятно что програмер если захочет, то может сделать и один free, и два, и десять.
    А потом попробовать обратиться к мертвому объекту.

    Но представь у тебя есть две дороги, одна двухполосная без отбойника, а другая такая же но с отбойником. Как думаешь, где плохих аварий будет больше?

     
  • 3.26, Аноним (26), 12:49, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Да господи, язык тот тут причем?

    При том, что он не должен не должен пропускать подобные банальные штуки.
    Если язык не может, значит нужно использовать чекеры, санитайзеры и прочие утилиты для обнаружения детских ошибок.
    Если ни язык, ни экосистема этого языка не позволяют создать 100% защиту от подобных ошибок, значит виноват язык.
    Здесь часто говорят, что "проблем нет, надо просто использовать простой советский...", но что-то в больших проектах никак не найдёт способ избавиться от детских болезней. Вывод очевиден - это невозможно, и виной - язык.

     
     
  • 4.33, ИмяХ (ok), 13:18, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>значит нужно использовать чекеры, санитайзеры и прочие утилиты для обнаружения детских ошибок

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

     
     
  • 5.35, Аноним (-), 13:32, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Давай воспользуемся бритвой Хэнлона и попытаемся не приписывать злому умыслу то... большой текст свёрнут, показать
     
     
  • 6.122, ProfessorNavigator (ok), 12:54, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Еще можно вспомнить классные аргументы от самых знающих анонимов "автотесты долго бегут, я нехочу ждать даже 10 минут!", "настоящие программисты таких глупых ошибок не делают", и "я просто проверяю код и все работает" от Профессор Навигатор.

    Профессор всё видит. На экзамене встретимся))

    А касательно проверки - единственная гарантия того, что код будет работать, как задумано - полное и тщательное тестирование всех функций и сценариев работы. Всё. Остальное никаких гарантий не даёт. Точнее даёт - что вы напихаете ещё больше ошибок. Если на тестировании код не работает, как задумывалось, и вы не может понять, в чём причина, только тогда можете воспользоваться системами автоматической проверки. Чтобы выявить проблемный участок. Затем переписать, и снова на тест. Повторять до получения приемлего результата.  

     
  • 5.60, Аноним (60), 15:27, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сам Линус как был замшалым финским студентом с версией 0.1, так и остался им на всю жизнь. Отсюда и все беды Linux. В академических осях инновации более осмысленные. Как следствие, проблемы намноооого реже. Линуса от управления разработкой ядра надо давно смещать. Сейчас в ядро тянется все подряд, а Линус, как собачка на торпеде, одобрительно на всё.
     
     
  • 6.90, Аноним (65), 19:20, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Только вот академический Minix имеет практических использований раз (IntelME)... и всё, в отличие от неакадемического.
     
     
  • 7.99, Аноним (-), 22:19, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Подумаешь, сотни миллионов процессоров по всему миру.
    Вот тебе и академический код)
    А еще можно вспомнить всякие нетфликсы и амазоны.
    И старую маоксь...

    О, вспомнил еще про ThreadX, которая сейчас Azure RTOS - 20 лет в проде, более 12 миллиардов устройств, успешный коммерческий проект.
    Это тебе не дырявое ядро впаривать.

     
  • 4.43, Витюшка (?), 14:16, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В ядре часто код который в main попадает тупо банально даже не компилируется!!! На это раз жаловался сам Линус. Так что до стадии "виновата С дыряшка" там просто не дошли.
     
     
  • 5.46, Анонин (-), 14:27, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > в main попадает тупо банально даже не компилируется

    Серьезно?
    А можно ссылки на PR или обсуждения?

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

    PS: как вообще можно залить некомпилируемый код? Его же CI не пропустит.

     
     
  • 6.61, User (??), 15:27, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > PS: как вообще можно залить некомпилируемый код? Его же CI не пропустит.

    Хе-хе-хе. Какой-такой си-ай хен-тай? Мы такого не знай - вон, оно в почту пролезай - фигли еще надо?!

     
  • 6.75, Витюшка (?), 16:40, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Естественно я сейчас не найду. Там очень много чего не работает на других архитектурах.

    Те код (общий) не компилируется под какую-то архитектуру, не то что не тестируется. На это Линус и жаловался. Какая-то там архитектура не помню, но не прямо какая-то экзотическая, risc-v типа того. Он в итоге завернул этот код (он прилетел из веток linux-next или какой-то подсистемы).

    Те он решил что-то сам ручками потестить, а оно даже не скомпилировалось :))

    Ни про какие CI я не слышал в Linux kernel.

     
     
  • 7.79, Анонин (-), 17:33, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Спасибо за пояснение. Нашел.
    То что на это сагрился сам Торвальдс всё существенно упростило))

    "Your testing is seriously lacking.
    This doesn't even build."
    lore.kernel.org/dri-devel/CAHk-=wgPJttFz8yrdpPTN-ypMmDXHOKw9yi1nZSEq+7+tGftZA@mail.gmail.com/

    Хорошо живут разрабы ядря.
    Вот мне, смузихлебу, нужно чтобы прошел линтер, код скомпилился под все целевые таргеты и прошли все тесты.
    И только тогда оно попадает на ревью.
    А если что-то меняешь - то тесты бегут заново. И ревью тоже сбрасывается((

    С другой стороны, разрабы ядра люди занятые, на них большая ответственность.
    Поэтому они могут ответственно сказать "LGFM" и замерджить.

     
  • 3.27, Аноним (27), 12:53, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    В нормальных же языках такое в принципе нельзя сделать. Памятью там управляет не программист, а сборщик мусора.
     
     
  • 4.32, Аноним (22), 13:17, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    При написании ядра сборщики мусора обычно неработают.
     
     
  • 5.48, Аноним (27), 14:38, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ответ был на фразу "да причем здесь языки вообще". Что стоит использовать или нет в ядре - это существенный вопрос конечно, но другой.
     
  • 4.34, Аноним (11), 13:29, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты хотел сказать в игрушечных языках.
     
     
  • 5.50, Аноним (27), 14:42, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ок, продолжайте использовать неигрушечные, позволяющие заинтерисованным лицам всегда иметь незакрытые дыры в линуксах
     
  • 5.144, Аноним (144), 03:47, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    игрушечных? то, что они не предназначены для системного программирования/embedded/жесткого реального времени не мешает языкам со сборкой мусора доминировать во всех остальных областях, так как в абсолютном большинстве случаев конечному потребителю ПО плевать на задержки, пока они от нескольких десятков до пары сотен миллисекунд.
     
  • 3.51, Аноним (-), 14:48, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну обнулишь ты указатель, можешь даже сделать memset(ptr, 0, len), а сишечка возьмет да и выбросит твое обнуление.
    О - оптимизация.

    https://wiki.sei.cmu.edu/confluence/display/c/MSC06-C.+Beware+of+compiler+opti

     
     
  • 4.69, Аноним (19), 16:08, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тогда asm volatile заинлайнить, где тупо xor делается, такое по идее не должн... большой текст свёрнут, показать
     
     
  • 5.73, Аноним (73), 16:33, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Странно, обычно адепты СИ просто писаются от осознания сколько платформ поддержи... большой текст свёрнут, показать
     
  • 5.81, Аноним (-), 17:47, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > если раст такое позволяет из коробки делать, то велик шанс того, что такие концепции работы с памятью вообще могут стереться из общественного сознания через пару поколений

    Если будут не нужны, то сотрутся так же, как навыки разведения огня без зажигалки, или умение считать в уме без калькулятора. Если будут востребованы, то никуда они не денутся.

     
  • 5.84, Аноним (-), 18:08, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот я о чем: если раст такое позволяет из коробки делать, то велик шанс того, что такие концепции работы с памятью вообще могут стереться из общественного сознания через пару поколений

    Они либо полезные, либо их не так уж жалко.

    Родители рассказывали как картошку копать, в поездках в колхоз от университета.
    Моя бабаушка рассказывала как стирать белье в проруби и как косить корм скотине.
    Думаю ее родител могли бы рассказать как чистить примус или разжигать дровяную печку.
    Я уже молчу про древних-древних предков, которые рассказали бы (при помощи 50 звуков и нескольких жестов) как сделать надежную палку-копалку, выбрать кремнь для каменного наконечника и как свалить мамонта.

    Но мне эти навыки нафиг не упали. И я надеюсь, что и не понадобятся.

     
  • 4.98, Аноним (98), 21:24, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не совсем по теме, но очень нравится, как там взяли решение из документа комитета[1], но поменяли слова "некоторые компиляторы выкидывают volatile в нарушение стандарта" на "выкидывают в строгом соответствии со стандартом".

    "should work on any standard-compliant platform. There has been recent notice that some compilers violate the standard by not always respecting the volatile qualifier."
    ==>
    "calling functions and accessing volatile-qualified objects can still be optimized out (while maintaining strict conformance to the standard)"

    [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf

     
  • 3.70, fidoman (ok), 16:14, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Угу, а также найти все прочие указатели на эту область памяти, и тоже обнулить.
    И ядру сказать, вот я передавал указатель при вызове асинхронной функции, его тоже обнули.
    Если бы всё так просто решалось...
     
  • 3.83, Аноним (-), 18:06, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В этой уязвимости я б сказал язык действительно не при чём Но тут ты не прав ко... большой текст свёрнут, показать
     
     
  • 4.112, n00by (ok), 11:44, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Но найти все указатели хранящие данный адрес в общем случае может только
    > сборщик мусора.

    В частном хватает std::shared_ptr<>.

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

    Это делает std::unique_ptr<>.

    А Rust что делает? unique_ptr выполняет на этапе компиляции, а в остальных случаях просто бьёт по руками и не позволяет написать код? Или там свой std::shared_ptr<> для неопределённого на этапе трансляции количества указателей?

     
     
  • 5.118, Аноним (-), 12:26, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > unique_ptr выполняет на этапе компиляции

    Если очень-очень упрощенно - то да. Только unique_ptr нужно проверять на empty, а тут не нужно.

    > а в остальных случаях просто бьёт по руками

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

    > и не позволяет написать код

    Не позволяет писать заведомо невалидируемый код.

    Но у раст есть свои аналоги shared_ptr:
    Rc - Single-threaded reference-counting pointer (doc.rust-lang.org/std/rc/struct.Rc.html)
    Arc - Thread-safe reference-counting pointer (doc.rust-lang.org/std/sync/struct.Arc.html)

     
     
  • 6.123, n00by (ok), 13:02, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> и не позволяет написать код
    > Не позволяет писать заведомо невалидируемый код.
    > Но у раст есть свои аналоги shared_ptr:
    > Rc - Single-threaded reference-counting pointer (doc.rust-lang.org/std/rc/struct.Rc.html)

    Не подходит, код ядра выполняется в произвольном потоке.

    > Arc - Thread-safe reference-counting pointer (doc.rust-lang.org/std/sync/struct.Arc.html)

    The type Arc<T> provides shared ownership of a value of type T, allocated in the heap.

    В ядре в общем случае нет кучи.

    If you need to mutate through an Arc, use Mutex, RwLock, or one of the Atomic types.

    То есть выбор сводится к:
    1. Написать заведомо невалидируемый код.
    2. Висеть в примитивах синхронизации, как и в наивной реализации std::shared_ptr.

     
     
  • 7.125, Аноним (-), 14:51, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Для ядра возможно есть специальные конструкции.
    Но какие именно не скажу, это нужно лезть в соответствующую ветку rust-for-linux и смотреть что нового.
    Или в ядро, если кода уже перенесли.
    Но т.к. я ни разу не ядерщик, то умываю руки)
     
     
  • 8.137, n00by (ok), 17:49, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Суть в том, что если всё это переносится в рантайм, то преимущества перед плюсам... текст свёрнут, показать
     
     
  • 9.139, Анонин (?), 18:17, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще новость как раз про то, что корректность важнее скорости Потому что кака... текст свёрнут, показать
     
     
  • 10.140, n00by (ok), 18:59, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А главное, что комментировать новость может всякий Даже не имея представления, ... текст свёрнут, показать
     
  • 7.142, Аноним (-), 20:07, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это может быть не важно, в каком потоке он выполняется Главное чтобы к Rc не бы... большой текст свёрнут, показать
     
     
  • 8.146, n00by (ok), 11:44, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Такие попытки как раз и будут Приложение вызвало syscall, далее поток работает ... большой текст свёрнут, показать
     
     
  • 9.150, Аноним (-), 15:40, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Представь себе ситуацию let global_structures Mutex new GlobalStructures ne... большой текст свёрнут, показать
     
     
  • 10.153, n00by (ok), 19:39, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Подобный подход вообще не очень хорош, потому что все вы... большой текст свёрнут, показать
     
  • 5.141, Аноним (-), 19:44, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты сейчас говоришь про случай описанный в новости, или просто произносишь общую ... большой текст свёрнут, показать
     
     
  • 6.147, n00by (ok), 12:23, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вот прямо сейчас я начну говорить о том, что не стоит вырезать контекст вернул ... большой текст свёрнут, показать
     
     
  • 7.151, Аноним (-), 16:12, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это решается интеллектом, который должен остановиться и подумать, что речь идёт ... большой текст свёрнут, показать
     
     
  • 8.152, n00by (ok), 18:46, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Вот эту последнюю проблему и решает RAII Всё освобождае... большой текст свёрнут, показать
     
  • 3.103, Аноним (103), 00:16, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Шутите? Это вина только языка. Язык такие вещи должен как минимум предотвращать, как максимум не требовать. А C - это по современным меркам и не яп вовсе.
     

     ....большая нить свёрнута, показать (44)

  • 1.8, Аноним (8), 11:38, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какого лешего io_uring можно отключить только переконпеляцией? Почему не сделают аргумент командной строки, чтоб можно было продолжать использовать дистрибутивные ядра, но без io_uring?
     
     
  • 2.10, НяшМяш (ok), 11:48, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    https://docs.kernel.org/next/admin-guide/sysctl/kernel.html#io-uring-disabled

    Должен быть доступен с версии ядра 6.6

     
     
  • 3.13, Аноним (8), 11:53, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо, мил-человек!
     

  • 1.29, Аноним (29), 12:55, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что такое этот io_uring и можно ли его отключить?

    И да, кто-то тестил у себя этот эксплоит? Что он делает с системой?

     
     
  • 2.42, Аноним (-), 14:10, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что такое этот io_uring

    man io_uring
    или хотя бы wikipedia.org/wiki/Io_uring

    > и можно ли его отключить?

    В ядра 6.6+ можно. https://docs.kernel.org/next/admin-guide/sysctl/kernel.html#io-uring-disabled

    >Что он делает с системой?

    Он получает рут и больше ничего не делает. Потому что пруф, а не зловред.
    А в реальности он бы делал что хотел.

     

  • 1.39, Аноним (-), 13:41, 01/04/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –1 +/
     
  • 1.40, uis (??), 13:45, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Многопоток опять гадит
     
  • 1.47, Аноним (19), 14:36, 01/04/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –1 +/
     

     ....ответы скрыты (4)

  • 1.49, Golangdev (?), 14:38, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > В настоящее время публично доступен работающий эксплоит, а также подробно описана вторая техника эксплуатации уязвимости.

    вот это я понимаю, предоставили пруф.


    а не то как другие - типа "-ааа, уязвимость, ааа, паника, срочно покупайте наш ссаный антивирус, но пруфа мы не предоставим"

     
  • 1.67, Аноним (67), 15:45, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Проблема проявляется начиная с выпуска ядра Linux 6.4

    Новые выпуски ядра должны решать проблемы, а не создавать их

     
     
  • 2.71, Аноним (73), 16:20, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Проблема проявляется начиная с выпуска ядра Linux 6.4
    > Новые выпуски ядра должны решать проблемы, а не создавать их

    Если бы так было, то ядро стало бы мегастабильным.
    И тогда вся орава писак просто стала бы ненужна.
    А как бродатый комми говорил? "на GPL коде можно заработать только на поддержке и/или исправлении уязвимостей".
    Вот они и стараются)


     
     
  • 3.80, Аноним (80), 17:34, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > И тогда вся орава писак просто стала бы ненужна.

    А как бродатый комми говорил? "на GPL коде можно заработать только на поддержке и/или исправлении уязвимостей".

    Ссылку на цитату не приведёшь?

     
     
  • 4.82, Аноним (-), 17:59, 01/04/2024 Скрыто ботом-модератором     [к модератору]
  • +2 +/
     
     
  • 5.113, n00by (ok), 11:51, 02/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 6.115, Аноним (-), 11:58, 02/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 7.120, n00by (ok), 12:42, 02/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 6.119, Аноним (-), 12:29, 02/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 7.121, n00by (ok), 12:44, 02/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 6.132, Аноним (-), 16:22, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не соглашусь, тк он в пример приводит агенство вроде Национального научного фон... большой текст свёрнут, показать
     
     
  • 7.136, n00by (ok), 17:35, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что Столлман срисовал идею с ГосФАП - вполне возможно. Есть и версия по этому поводу, что ЦРУ посчитали хранимый там объём исходников под PDP11, сравнили со своим, а в итоге DEC совершенно случайно приказала долго жить. Некоторые на такую версию вешают ярлык "конспирология", но при этом забывают, что DEC поднялась на госзаказах (как и IBM, но от другого ведомства).

    Разница в том, что в СССР была одна партия, а в США - две. И кто стабильно голосует за победителя на выборах, тому и достаётся финансирование в случае победы. Единый центр получил бы там слишком много власти, вплоть до возможности навязывать свою волю производителям железа, а через них и вообще задавить республиканцев.

     
  • 5.129, Аноним (-), 15:56, 02/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 6.130, Аноним (-), 16:05, 02/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.74, BorichL (ok), 16:39, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да надо просто работать из-под учётки root, тогда на все эти уязвимости насрать  ;-)
     
     
  • 3.86, Аноним (-), 18:20, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ????? Поясни мысль. ты хотел сказать, что "не надо просто работать из-под учётки root".
     
     
  • 4.88, BorichL (ok), 18:42, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ????? Поясни мысль. ты хотел сказать, что "не надо просто работать из-под
    > учётки root".

    Нет, не надо быть зассыхой и надо работать из-под учётки root, тогда все уязвимости в получении прав root'а теряют смысл   ;-)

     
  • 3.91, Аноним (65), 19:27, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Привет, чудный мир POSIX-DOS!
     
  • 3.92, вася (??), 19:33, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Нужно просто из квартиры выпилить входную дверь и тогда на все эти проблемы со взломом замков будет нacpaть
     
  • 3.94, Аноним (65), 19:43, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Просто заходи в /bin, /usr/bin, /sbin, /usr/sbin и свободно модифицируй любые файлы там. Да хоть все. И в чём прелесть, что для этого не надо ничего ломать. Вот тогда вирусам для Linux точно цвесть.
     

     ....большая нить свёрнута, показать (18)

  • 1.93, Андрей (??), 19:41, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
     gcc exploit.c
    exploit.c:5:10: фатальная ошибка: liburing.h: No such file or directory
        5 | #include "liburing.h"
          |          ^~~~~~~~~~~~
    компиляция прервана.
     
     
  • 2.95, Аноним (95), 19:50, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не знаешь как подключить liburing.h? Фатальная ошибка!
     
     
  • 3.96, Андрей (??), 20:52, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    выброс дофаминов получил ?:)
     
     
  • 4.97, Аноним (89), 20:56, 01/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    apt install liburing-dev
     

  • 1.100, sena (ok), 22:37, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не компилируется

    cc     exploit.c   -o exploit
    exploit.c: In function ‘hppa_br_setup’:
    exploit.c:81:12: error: ‘struct io_uring_buf_reg’ has no member named ‘flags’
       81 |         reg.flags = IOU_PBUF_RING_MMAP;
          |            ^
    exploit.c:81:21: error: ‘IOU_PBUF_RING_MMAP’ undeclared (first use in this function)
       81 |         reg.flags = IOU_PBUF_RING_MMAP;
          |                     ^~~~~~~~~~~~~~~~~~
    exploit.c:81:21: note: each undeclared identifier is reported only once for each function it appears in
    exploit.c:90:15: error: ‘IORING_OFF_PBUF_RING’ undeclared (first use in this function); did you mean ‘IORING_OFF_CQ_RING’?
       90 |         off = IORING_OFF_PBUF_RING | (unsigned long long) bgid << IORING_OFF_PBUF_SHIFT;
          |               ^~~~~~~~~~~~~~~~~~~~
          |               IORING_OFF_CQ_RING
    exploit.c:90:67: error: ‘IORING_OFF_PBUF_SHIFT’ undeclared (first use in this function); did you mean ‘IORING_CQE_BUFFER_SHIFT’?
       90 |         off = IORING_OFF_PBUF_RING | (unsigned long long) bgid << IORING_OFF_PBUF_SHIFT;
          |                                                                   ^~~~~~~~~~~~~~~~~~~~~
          |                                                                   IORING_CQE_BUFFER_SHIFT

     
     
  • 2.117, n00by (ok), 12:26, 02/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что в 2.5 этого нет https://github.com/axboe/liburing/commit/9c6689848ebf79a5830258c6416101b86b05f
    Брать надо из git
     

  • 1.106, Аноним (-), 03:12, 02/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >и доступа к соседним физическим страницам памяти

    опять RowHammer?

     
  • 1.109, Tron is Whistling (?), 09:56, 02/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Что, опять (tm)
    Ну вот зачем это в ядре по умолчанию, а. Кому оно нужно кроме полутора мегамонстров?
     
     
  • 2.145, платиновый спонсор (?), 11:36, 03/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну вот зачем это в ядре по умолчанию, а. Кому оно нужно кроме полутора мегамонстров?

    Ядро-то ? Правильно, никому оно ненужно. В смысле - настолько чтобы платить вашему б-жку с пальцем по ляму долларов в месяц.

    Поскреби по кармашкам - может, найдешь?

    Хахаха! Вот поэтому мы этот дэушка и будим танцыват. Ну и кое что после танцев.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру