Профиль: Аноним (вход | регистрация) неRU opennet.me  
The OpenNET Project / Index page

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



"PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющие получить root через изменение страничного кэша"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющие получить root через изменение страничного кэша"  +/
Сообщение от opennews (??), 27-Июн-26, 00:24 
Раскрыта информация о двух новых уязвимостях в ядре Linux, позволяющих непривилегированному пользователю получить права root, перезаписав данные в страничном кэше. Для обеих уязвимостей подготовлены рабочие эксплоиты...

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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 27-Июн-26, 00:24   +2 +/
Опять? Это какой уже раз, 5?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #4, #5, #9, #40

2. Сообщение от Аноним (3), 27-Июн-26, 00:28   +/
Сейчас бы послушать тех, кто тут заливает, что AI ничего не может и раст не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #8, #10, #11, #13, #35

3. Сообщение от Аноним (3), 27-Июн-26, 00:29   –4 +/
Так выводы же не делают. Давно пора принимать коммиты исключительно на раст. А на си только фиксы уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6, #24, #48

4. Сообщение от Аноним (4), 27-Июн-26, 00:31   +3 +/
Восьмой:
https://www.opennet.dev/65325
https://www.opennet.dev/65395 x2
https://www.opennet.dev/65441
https://www.opennet.dev/65473
https://www.opennet.dev/65476
https://www.opennet.dev/65504
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

5. Сообщение от Аноним (6), 27-Июн-26, 00:40   –3 +/
Я ж говорил, что через неделю новые будут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

6. Сообщение от Аноним (6), 27-Июн-26, 00:47   –3 +/
Давно пора сменить систему управления проектом вместе с начальством.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #29

7. Сообщение от Аноним (-), 27-Июн-26, 01:06   +5 +/
Лучше бы слушали тех, кто про микроядро говорил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

8. Сообщение от Аноним (8), 27-Июн-26, 01:36   +/
>что AI ничего не может

Гораздо хуже не то, что AI чего-то не может, в этом случае с ним бы поигрались, и отложили бы в сторону. Гораздо хуже то, что обнаружение уязвимостей, вместо того, чтобы быть разовым и исчерпывающим, растягивается на месяцы. Новость о первой уязвимости датируется 30.04.2026, текущей - 26.06.2026. Прошло около двух месяцев, а дыра оставалась неисправленной, и вполне возможно, эксплуатируемой. Более того, если кто-то захочет провести самостоятельный аудит, то есть вероятность, что он не сможет это сделать, так как свободные модели окажутся недостаточно развитыми для этого, а собственнические будут либо закрыты, либо на них будет висеть цензурное ограничение.
>и раст не нужен.

Действительно не нужен. К сожалению, основное достижение раста - популярность. Если убрать в сторону его удобство, вроде cargo, то достоинства раста будут привлекательными только на фоне всяких сишек. Поскольку в расте нет линейных типов, то как следствие, он никак не препятствует утечкам памяти. В нём нет зависимых типов, что позволит сделать индексацию массива безопасной, без проверок времени исполнения, как в си. В нём нет алгебраических эффектов, по этому часть ошибок будет вызывать панику просто потому, что растовики не решились это завернуть в монады, и тот код, который на си писался одним if-ом, в rust потребует изобретения велосипеда. Зато сейчас, когда поезд уже ушёл, в стандартной библиотеке висит ночнушка, позволяющая всё-таки это реализовать. Но конечно же, в каждой из 100500 библиотек этого не будет. Кучи других свойств, вроде того же GADT в него тоже не завезли.

Самый главный недостаток раста - это его популярность. Лучшее - враг хорошего. Программисты крайне неохотно избавляются от своего любимого язычка. Выучив его, они будут пихать его до тех пор, пока его можно запихнуть, даже если другой язык тоже смог бы справится с их запросом. Почитайте тот же waycooler posmortem, как они на ровном месте создали себе проблему, которую не смогли преодолеть. При этом, языку, который будет решать больше проблем, будет крайне сложно пробиться, так как всё, раст их затмил, как самый модный, молодёжный язык. Парадокс Блаба дерижит растовиков как бы не крепче сишников.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

9. Сообщение от Аноним (9), 27-Июн-26, 01:46   +/
Не опять, а снова!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

10. Сообщение от Аноним (9), 27-Июн-26, 01:47   +/
Сломать всегда проще, чем создать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

11. Сообщение от Аноним (11), 27-Июн-26, 01:51   +/
Вопрос не в том, может ли AI (Adolf Itler) что-то или не может, вопрос в том, может ли человек доверять ему и выявлять западло им подложенное и скрытое, хотя бы логической обфускацией.

А раст... Существует ли раст без ансафе? А то стоит как бочка варенья с размешанной в ней ложкой дерьма, а "сиротки" "страдающие" от наСИлия хавают, хавают...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #12

12. Сообщение от q (ok), 27-Июн-26, 03:10   +1 +/
> бочка варенья с размешанной в ней ложкой дерьма

Она не размешана, а строго изолирована блоком unsafe. В твоей аналогии, это ложка дерьма, запечатанная в варенье-непроницаемый пакетик. Можно его в любой момент извлечь, заменив safe-кодом. Ну а в сишке буквально каждая вторая строка unsafe. Что уж говорить, там даже int + int = undefined behavior.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

13. Сообщение от Ivan_83 (ok), 27-Июн-26, 03:46   +/
AI бывает разный, есть тут у меня - он ничего не может кроме генерации нейрослопа :)
Есть получшее, генерят рабочие или почти рабочие примеры кода на заданную тематику (я обычно спрашиваю на уровне функций).
Есть которые хорошо анализируют код, но тоже им часто мерещится всякое.
Но тут на том кто этот AI пользует отвественность, чтобы он проверял каждый его вывод а не верил всему подряд.

Я уже видел идиотов с AI, им AI подтверждает и аргументирует любой их бред, в итоге они становятся ещё глупее, а кое кого наверное и в дурку после такого закрывают, на хабре был пример.

Раст реально не нужен, с приходом AI он устарел, теперь AI может пройтись по C коду как анализатор и подсказать что лучше исправить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #14, #18, #20

14. Сообщение от Аноним (14), 27-Июн-26, 04:03   +/
> Раст реально не нужен, с приходом AI он устарел, теперь AI может пройтись по C коду как анализатор и подсказать что лучше исправить.

По чем пройти? По 40+ миллионам кодовой базы?

И кто будет читать эти квинтиллионы ворнингов потом?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #15, #21

15. Сообщение от Анонимный Ананас (?), 27-Июн-26, 04:08   –1 +/
Пусть нейросети тупо берут и переписывают каждый файл с c++ на раст, в чём проблема?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #16, #22

16. Сообщение от Аноним (14), 27-Июн-26, 04:11   +2 +/
Ну если output не в /dev/null, то проблема будет с тем, что это просто слоп. В лучшем случае кое-как работающий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

17. Сообщение от Аноним (17), 27-Июн-26, 04:12   +/
user namespace - источник дыр.

Хотели как лучше, а получилось как всегда (c)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34

18. Сообщение от q (ok), 27-Июн-26, 04:34   +/
> AI может пройтись по C коду как анализатор и подсказать что лучше исправить

Ты действительно не отличаешь аналоговый анализ (на уровне "вайба", "ощущений") от формально-верифицируемых? Ну попробуй использовать LLM как калькулятор. Скажем, попроси его вычислить квадратный корень от 146, и сравни результат с реальным калькулятором. Причем это еще легкая задача, если сравнивать с растовской задачей по разбором всех мест, где ссылка боровится, мувится или шарится как-то еще. Как ребенку надо объяснять, ей богу. LLM никогда не будет формально-верифицируемым. Это тебе не A.L.I.C.E., где все паттерны прописывались вручную. Это тебе не OWL reasoners, где по RDF-стейтментам можно вычислить новые факты, используя формальную логику (используется в медицине). Это тебе не пролог, где тоже можно было отследить, по какой-такой причине Socrates is mortal (потому что Socrates is a Human, and a Human is mortal).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #19, #26

19. Сообщение от Аноним (8), 27-Июн-26, 04:46   +/
>Ну попробуй использовать LLM как калькулятор. Скажем, попроси его вычислить квадратный корень от 146

Вы встали на скользкую дорожку. Современные нейросети - давно не нейросети, а обвязка из кучи утилит. Подобно тому, как нейросеть может сформировать запрос и найти информацию в интернете, она точно так же может вызывать калькулятор или статический анализатор. Человек не понимающий отличие между калькулятором и нейросетью будет крайне легко введён в заблуждение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23, #25

20. Сообщение от Аноним (8), 27-Июн-26, 04:49   +/
А вы молодец. В вашей голове уживаются одновременно две мысли:
>Я уже видел идиотов с AI, им AI подтверждает и аргументирует любой их бред, в итоге они становятся ещё глупее
>Раст реально не нужен, с приходом AI он устарел

Вы определитесь, AI это хорошо или плохо?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #32

21. Сообщение от Ivan_83 (ok), 27-Июн-26, 04:57   +/
Не вижу проблемы.
По линуксам, фрям и прочим прошлись уже, никто не помер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #37

22. Сообщение от Ivan_83 (ok), 27-Июн-26, 04:58   +/
В том, что это на несколько порядков больше ресурсов потребует, а результат будет в случем случае такой же как от фикса С кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

23. Сообщение от q (ok), 27-Июн-26, 05:01   +/
> точно так же может вызывать калькулятор или статический анализатор

Читай его коммент внимательнее: "теперь AI может пройтись по C коду как анализатор". Подразумевая, что си-анализаторы тоже не нужны, так как существуют ЛЛМ.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #27

24. Сообщение от Аноним (24), 27-Июн-26, 05:03   +/
А новый функционал? На раст ведь переписывают, а не пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

25. Сообщение от Ff (?), 27-Июн-26, 05:03   +/
Подсели на чужой каравай чек поинт принт чай , а всего то говорилось на чужой каравай и так далее , за чужой поинт вернуть средства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

26. Сообщение от Ivan_83 (ok), 27-Июн-26, 05:08   –1 +/
Эта ваша формальная верифицируемость существует в вакууме, до первых ERRATA для платформы и ошибок в памяти.
Но как отмазка: я нивиноват, кампелятором раста клянусь! - вполне годно.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #28

27. Сообщение от Ivan_83 (ok), 27-Июн-26, 05:09   +/
Статические анализаторы - для них почти ничего не осталось, после того как в компилятор все варнинги повключаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #30

28. Сообщение от q (ok), 27-Июн-26, 05:19   +/
Так раст и есть конпелятор с варнингами и стат анализатор, додик. ИИ никогда не заменит точные инструменты. Даже в тех задачах, где от ИИ требуется что-то вычислить, правильнее его спрашивать написать одноразовый питоноскрипт, чем пытаться заставлять его вычислять квадратные корни в уме.

Твой ИИ бесполезен без стат анализаторов.
ИИ сам считает себя бесполезным без стат анализаторов.

Раст+ИИ лучше, чем Си+ИИ. И нет, Си+ИИ не лучше просто раста без ИИ.

Rust+AI > Rust > C+AI > C

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #31

29. Сообщение от Аноним (29), 27-Июн-26, 05:20   +4 +/
Так сделай же форк, и стань начальником раз такой умный
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

30. Сообщение от q (ok), 27-Июн-26, 05:21   +/
> для них почти ничего не осталось, после того как в компилятор все варнинги повключаешь

Остались лишь такие пустяки, как ownership, move semantics и borrowing.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #36

31. Сообщение от Ivan_83 (ok), 27-Июн-26, 05:35   –1 +/
Потому что AI только повторяет базу обучения, вот он и пишет вам что раст лучше.

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

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

И от AI в таком случае требуется смотреть на всякие человеческие ошибки, уровня передали a,a хотя должны были передать a,b, не корректные применения функций и всякие другие интересные случаи.
Да, бывает по запарке и "индекс массивы" кто то посчитает не корректно или после десятка валидных мержей результат становится невалидным - тут AI хороший помошник, лишние глаза которые не устают.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #38

32. Сообщение от Ivan_83 (ok), 27-Июн-26, 05:36   +/
AI хорошо, раст ненужно.
Не вижу там противоречий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

33. Сообщение от Ivan_83 (ok), 27-Июн-26, 05:38   +/
Хотел было порекомендовать простой фикс для всех проблем с pagecache: флюшить/не использовать для setuid процессов, но там же начнут passwd и прочие файлы так же "перезаписывать"...

Но как обычно почти всё сводится: не включай неймспейсы...

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51

34. Сообщение от Ivan_83 (ok), 27-Июн-26, 05:41   +/
Не то чтобы.
Иногда бывает идея хорошая, но реализация изначально такая что потом никакими парустрочными коммитами/фиксами не исправить, только выкинуть/переписать.
ringbuf такой же в линуксе.
Но остальные подсистемы вроде вполне, судя по новостям с ошибками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #47

35. Сообщение от Аноним (35), 27-Июн-26, 05:48   +/
> раст не нужен

Нет, не нужен. Есть Frama C, SPARK, Isabelle, Rocq и много ещё чего. На них, правда, не нанейрослопишь, на них думать нужно, а у растоманов, как известно, с этим проблемы - постоянно логические ошибки допускают.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

36. Сообщение от Ivan_83 (ok), 27-Июн-26, 06:01   +/
Это всё решается на архитектурном уровне, то что это опустили на уровень языка говорит только об уровне програмной инженерии: что то написал, хз что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #39

37. Сообщение от Аноним (14), 27-Июн-26, 06:06   +/
И толку? Допустим прошлись, но мы с Вами общаемся в топике про очередную уязвимость.

А по факту, во сколько обходится по времени и деньгам проход всей кодовой базы того же ядра, тем же Mythos, с парой триллионов активных параметров?

Я сильно сомневаюсь, что ним прошлись по всему ядру.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #44

38. Сообщение от q (ok), 27-Июн-26, 06:11   +/
> Потому что AI только повторяет базу обучения, вот он и пишет вам что раст лучше

Он повторяет обычную логику: в точных задачах, точные инструменты лучше вайбовых. Докажи обратное.

> всё сводится к горе простейших С функций, которые легко проанализировать и валидировать по отдельности

В хелловорлд-проектах -- да. В чем-то посложнее начинаются неизбежные оптимизации вроде шаренного стейта, и тут уже изменение в одном месте резко влияет на всё остальное. Удачи всунуть весь проект в контекст ЛЛМ!

А уж про экономию ресурсов я и вовсе молчу: стат анализатор жрет меньше, работает на порядки быстрее, и гарантированно точен. С ИИ, тебе либо повезет, либо не повезет, в зависимости от temperature, seed и прочих рандомизаторов. На один и тот же хитрый вопрос ИИ выдаст противоположные результаты в зависимости от... случайного seed мля.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #42

39. Сообщение от q (ok), 27-Июн-26, 06:14   +/
> Это всё решается на архитектурном уровне

А на уровне языка это решается надежнее.

> говорит только об уровне програмной инженерии: что то написал, хз что

ИИ пишет хз что, так как срисован с человека и допускает человеческие же ошибки, галлюцинируя на ходу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #43

40. Сообщение от Василий (??), 27-Июн-26, 06:25   +/
Это один в один как с уязвимостями, эксплуатирующие изъян со спекулятивным выполнением команд ЦПУ. Нужно ждать радикального решения проблемы с отравлением страничного кэша. Но когда отцы основатели решат, хз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

41. Сообщение от Syndrome (ok), 27-Июн-26, 06:32   +/
Уязвимости в подсистеме «user namespaces», а не в ядре Линукса. Заголовок не помешало бы исправить.
Ответить | Правка | Наверх | Cообщить модератору

42. Сообщение от Ivan_83 (ok), 27-Июн-26, 06:52   +/
Так и С не даёт писать код: "эта, ойпта, быра сделай мине биткойн этот самый с 100 битками!".
А то что там в расте по дефолту -Werror особой разницы не делает.


> В чем-то посложнее начинаются неизбежные оптимизации вроде шаренного стейта

Вот в драх ОС как то на С проблемы нет такое сделать.


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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #46

43. Сообщение от Ivan_83 (ok), 27-Июн-26, 06:56   +/
На уровне языка который претендует на замену крестам и даже С это костыль.
Типа раньше надо было уметь в архитектуру, а теперь тебя компилятор будет п...ругать пока ты не сбрутфорсишь вариант который ему понравится или на напишешь unsafe чтобы он заткнулся наконец.

Я не предлагаю заставлять ИИ писать всё единолично.
Хотя там некоторые собирают консилиумы из разных ИИ и заставляют их выдавать нечто нормальное.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #45

44. Сообщение от Ivan_83 (ok), 27-Июн-26, 07:00   +/
А зачем делать это часто?
Обычно есть предрелизная заморозка кода, вот во время неё и прогонять.

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

Лично я прогоняю уже именно перед релизом.
А в процессе мне хватает -Wall (и ещё пары подобных флагов).

Как итог для ИИ код приходит уже без тупых ошибок и мелочёвки, и остаётся только сложное и интересное.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

45. Сообщение от q (ok), 27-Июн-26, 07:21   +/
> На уровне языка который претендует на замену крестам и даже С это костыль.

Ты явно не программист, ибо не владеешь базовой терминологией. Костыль -- это когда архитектура не позволяет сделать что-то, и ты огородами и задними ходами добиваешься чего-то. А в расте правила ownership -- это и есть архитектура, поэтому костылем не может быть по определению. Удачная ли эта архитектура? Абсолютно.

> раньше надо было уметь в архитектуру

Архитектура не решает вопросов ownership. Это уже уровень проектирования.

> пока ты не сбрутфорсишь вариант который ему понравится

Кто-то брутфорсит, кто-то пишет изначально корректно. В обоих случаях оба пишут memory-safe код, что и было изначальной задумкой.

> Я не предлагаю заставлять ИИ писать всё единолично

Ты предлагаешь использовать ИИ ВМЕСТО стат. анализаторов. Читай сам свой коммент: "AI может пройтись по C коду как анализатор".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

46. Сообщение от q (ok), 27-Июн-26, 07:32   +/
> Так и С не даёт писать код: "эта, ойпта, быра сделай мине биткойн этот самый с 100 битками!".

Не распарсил твой пример. Изъясняйся на русском.

> А то что там в расте по дефолту -Werror особой разницы не делает.

Делает. В растовых проектах максимальные проверки идут изначально, куда ни загляни. В сишных же тебе надо идти уговаривать авторов, на что они тебе ответят, что они вумные и не позволят сишному конпелятору вставать у них на пути. "Нет, я вумный. Я знаю что делаю. Я гений. Я вумнее." А потом х-як -- и CVE.

> Вот в [я]драх ОС как то на С проблемы нет такое сделать.

Проблемы сделать нет. Есть проблемы с тысячами (десятками тысяч?) CVE, которые идут из-за отсутствия ownership-проверок в сишечке. C in CVE stands for C, гы.

> С c -Werror работает ещё быстрее и с такой же точностью.

Не с такой же. Он не проверяет ownership.
И вообще, лично ТЫ не включишь -Werror, "патаму шта у меня ИИ, щачем мне стат анализатор" (дословная цитата твоей мысли).

> мегапроверки раста каждый раз только мешаются

Не мешаются. Именно благодаря им пишется memory-safe код. Плохому танцору...

> нормальные люди не включают -Werror для отдаточных сборок и в процессе работы

Нормальные люди -- включают всегда. Они их и не вырубают никогда. Они даже вопросом таким не задаются, "а не отключить ли бы мне -Werror". Им такое в голову просто не приходит. Если ты им это предложишь, они покрутят у виска и попросят тебя покинуть заведение немедленно, параллельно нажимая на кнопку вызова охраны.

> Процесс анализа нужен уже тогда когда есть код и он работает, вот мой поинт

Хороший поинт, но "кодить быстро" принято в скриптовых языках, а не в системных. Я понимаю, если ты в тайпскрипте быстренько добавишь // @ts-ignore, чтоб проверить гипотезу. В системных языках такой флоу не используется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

47. Сообщение от Аноним (17), 27-Июн-26, 07:40   +/
В io_uring регулярно дыры находят, вроде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

48. Сообщение от Аноним (48), 27-Июн-26, 07:48   +/
Это вопрос не раста, а оптимизаций. Либо перекладывать байты из буфера в буфер, тратя на это процессор и оперативку, либо переписывать буфер на месте. И тут уже совершенно не важно - чем ты будешь этот буфер переписывать, шансы улететь за его пределы одинаковые и у раста и си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

49. Сообщение от ИмяХ (ok), 27-Июн-26, 07:55   +/
>>Проблема проявляется начиная с ядра Linux 5.18

C сайта kernel.org:
Linux 5.18 was released on Sunday, 22 May 2022.
Бэкдор успешно проработал четыре года. А сколько бэкдоров в нём ещё работает?

Ответить | Правка | Наверх | Cообщить модератору

50. Сообщение от openssh_user (ok), 27-Июн-26, 07:55   +/
Есть пробитие
Ответить | Правка | Наверх | Cообщить модератору

51. Сообщение от Аноним (1), 27-Июн-26, 08:00   +/
А другой универсальной изоляции не придумали. Если тут полагаются на баги в кэше, то без неймспейсов векторов атаки намного больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33


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

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




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

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