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

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

форумы
правила/FAQ
поиск
регистрация
вход/выход
слежка
RSS


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

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

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

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

Оглавление

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


1. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +6 +/–
Сообщение от Аноним (1), 27-Июн-26, 00:24 
Опять? Это какой уже раз, 5?
Ответить | Правка | Наверх | Cообщить модератору

3. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –15 +/–
Сообщение от Аноним (3), 27-Июн-26, 00:29 
Так выводы же не делают. Давно пора принимать коммиты исключительно на раст. А на си только фиксы уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору

6. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –9 +/–
Сообщение от Аноним (6), 27-Июн-26, 00:47 
Давно пора сменить систему управления проектом вместе с начальством.
Ответить | Правка | Наверх | Cообщить модератору

29. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +14 +/–
Сообщение от Аноним (29), 27-Июн-26, 05:20 
Так сделай же форк, и стань начальником раз такой умный
Ответить | Правка | Наверх | Cообщить модератору

62. Скрыто модератором  +7 +/–
Сообщение от Мемоним (?), 27-Июн-26, 09:49 
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

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

75. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (75), 27-Июн-26, 11:49 
Вроде как все, что делала команда Asahi, изначально на Rust написано. У них даже пост где то был, почему rust и почему не С
Ответить | Правка | Наверх | Cообщить модератору

83. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +4 +/–
Сообщение от Аноним (83), 27-Июн-26, 15:13 
Тогда компромисс: писать на C и, как только заработало, тут же начинать переписывать на Rust.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

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

4. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +13 +/–
Сообщение от Аноним (4), 27-Июн-26, 00:31 
Восьмой:
https://www.opennet.ru/65325
https://www.opennet.ru/65395 x2
https://www.opennet.ru/65441
https://www.opennet.ru/65473
https://www.opennet.ru/65476
https://www.opennet.ru/65504
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

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

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

55. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –3 +/–
Сообщение от Tron is Whistling (?), 27-Июн-26, 08:40 
Ну как когда. Когда ты вместо A5 купишь A9 или вместо Core2 - i14. То же самое и с серверами.
Ответить | Правка | Наверх | Cообщить модератору

2. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –3 +/–
Сообщение от Аноним (3), 27-Июн-26, 00:28 
Сейчас бы послушать тех, кто тут заливает, что AI ничего не может и раст не нужен.
Ответить | Правка | Наверх | Cообщить модератору

7. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +16 +/–
Сообщение от Аноним (-), 27-Июн-26, 01:06 
Лучше бы слушали тех, кто про микроядро говорил.
Ответить | Правка | Наверх | Cообщить модератору

8. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +3 +/–
Сообщение от Аноним (8), 27-Июн-26, 01:36 
>что AI ничего не может

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

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

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

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

67. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –1 +/–
Сообщение от Cooler (??), 27-Июн-26, 10:20 
Интересный пост. Хотя есть ряд недосказанностей. Пиши ещё (без сарказма).
Ответить | Правка | Наверх | Cообщить модератору

95. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Прохожий (??), 27-Июн-26, 19:22 
В этом посте не просто ряд недосказанностей. В нём, скорее, очень небольшая толика правды. Лучше вообще не писать, чем выплёскивать в неокрепшие умы вот это варево.
Ответить | Правка | Наверх | Cообщить модератору

94. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Прохожий (??), 27-Июн-26, 19:19 
>>и раст не нужен.
>Действительно не нужен. К сожалению, основное достижение раста - популярность.

К сожалению, это несусветная чушь. Афинные типы, стандартные абстракции с нулевой стоимостью, Юникод из коробки, проверка заимствований, предотвращение гонок, развитая инфраструктура, всё это - достижения Rust.

> Если убрать в сторону его удобство, вроде cargo, то достоинства раста будут привлекательными только на фоне всяких сишек.

Если есть ещё какие языки, сравнимые по функциональности и скорости выполнения кода, хорошо было бы их привести. Потому что с чем ещё сравнивать, как не со всякими си-шками?

> Поскольку в расте нет линейных типов, то как следствие, он никак не препятствует утечкам памяти.

Очередная чушь, хотя здесь уже нельзя уверенно сказать, что несусветная. Rust, на самом деле, препятствует утечкам — просто не гарантирует их полное отсутствие. Rust гарантирует отсутствие use-after-free, double free, data races, висячих указателей и большинства классов ошибок управления памятью.

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

1. И снова ахинея. Массивы [T; N] имеют длину в типе.
```
fn get<const N: usize>(arr: [i32; N], idx: usize) -> i32 {
    arr[idx]
}
```

Компилятор знает N на этапе компиляции. Если idx — константа, проверка полностью исчезает в машинном коде. Это уже даёт compile‑time safety без зависимых типов.

2. Rust генерирует проверку границ массива, но LLVM удаляет её, если может доказать корректность.

3. Срезы &[T] и итераторы дают безопасный доступ без проверок

> В нём нет алгебраических эффектов, по этому часть ошибок будет вызывать панику просто потому, что растовики не решились это завернуть в монады, и тот код, который на си писался одним if-ом, в rust потребует изобретения велосипеда.

Rust решает эту проблему другим путём — через типы Result, Option, ?, FromResidual, Try, и zero‑cost абстракции.

> Зато сейчас, когда поезд уже ушёл

Разве что в голове некоего Воина Супротив Раста какой-то поезд куда-то ушёл. В реальности же "караван идёт, собаки лают".


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

100. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (8), 27-Июн-26, 23:56 
Вы прекрасно демонстируете свою неосведомлённость, вашим сообщением.
>Афинные типы

Именно благодаря этому память и течёт. Взяли бы линейные - проблемы бы не было.
>всё это - достижения Rust.

Вы рекламный буклет пишите?
>Если есть ещё какие языки, сравнимые по функциональности

Как минимум стоит вспомнить про Cyclone(почти тот же rust) и ATS, который даёт возможности, которых в rust отсутствуют.
>Rust, на самом деле, препятствует утечкам — просто не гарантирует их полное отсутствие

Memory leaks are memory safe - читайте до полного просветления. Rust абсолютно никак не мешает утечкам памяти.
>Rust гарантирует

Не нужно переводить стрелки, я и без вас знаю, что это есть.
>Массивы [T; N] имеют длину в типе.

Опять вы выдаёте желаемое за действительное. Почему вы умалчиваете о динамических массивах? Неужели по причине того, что это рушит вашу стройную картину мира?
>Rust генерирует проверку границ массива, но LLVM удаляет её, если может доказать корректность.

Вы уже признали отсутствие данной абстракции нулевой цены. Это буквально точно так же как в условном c#, когда проверка выполняется во время выполнения, и код, как мешок картошки, падает на пол.
>Rust решает эту проблему другим путём — через типы

Если я вам говорю, что не решает, не спорьте со мной, я прав. https://doc.rust-lang.org/std/boxed/struct.Box.html#method.t...
Вот, видите
>This is a nightly-only experimental API. (allocator_api #32838)

А теперь покажите мне try_ в абсолютно каждой библиотеке. Что, неужели отсутствует?
>и zero‑cost абстракции.

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

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

110. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +1 +/–
Сообщение от Прохожий (??), 29-Июн-26, 00:04 
>Вы прекрасно демонстируете свою неосведомлённость, вашим сообщением.

Где уж мне с вами сравняться.

>по этому часть ошибок будет вызывать панику просто потому, что растовики не решились это завернуть в монады

Result и Option — это монады.
Оператор ? — это монадический bind.
Try — это монадический интерфейс.
Вы бы хоть немного глубже вникали в то, что сами же утверждаете. Кто-то чуть ниже про нейронки говорил. Вот примените свой совет к себе для начала.

>>Афинные типы
>Именно благодаря этому память и течёт. Взяли бы линейные - проблемы бы не было

Читайте в следующий раз более внимательно, на что отвечаете. Память "течёт" НЕ ТОЛЬКО по этой причине, и все они были перечислены в моём предыдущем сообщении.

>>всё это - достижения Rust.
>Вы рекламный буклет пишите?

Нет, в отличие от вас я привожу факты, которые соответствуют реальности, а не занимаюсь незамысловатыми манипуляциями.

>>Если есть ещё какие языки, сравнимые по функциональности
>Как минимум стоит вспомнить про Cyclone(почти тот же rust) и ATS, который даёт возможности, которых в rust отсутствуют.

Но вы в предыдущем своём посте их не привели. Вот этот ваш аргумент принимается. Хотя Cyclone уже несколько устарел в плане работы с памятью, а ATS по сложности освоения хуже Rust.

>>Rust, на самом деле, препятствует утечкам — просто не гарантирует их полное отсутствие
>Memory leaks are memory safe - читайте до полного просветления. Rust абсолютно никак не мешает утечкам памяти.

Если уж кому и надо читать до просветления посты вашего оппонента, так это вам. Именно это я и имел ввиду, когда говорил, что полную гарантию на утечки памяти Rust не даёт.


>>Rust гарантирует
>Не нужно переводить стрелки, я и без вас знаю, что это есть.

К сожалению (или счастью) я - не телепат, поэтому не могу знать, о чём вы имеете представление, а о чём - нет. Раз вы решили замолчать этот факт, я логично предположил, что вы об этом представления не имеете. Но теперь вы признались, что имеете. Зачем тогда умолчали об этом?

> Почему вы умалчиваете о динамических массивах? Неужели по причине того, что это рушит вашу стройную картину мира?

А как динамические массивы связаны с зависимыми типами, которые в Rust отсутствуют?

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

Неа. Это вам так хочется. В итоге абстракция становится нулевой в данном конкретном случае, и я даже объяснил, как это происходит. В общем случае - да, возможны варианты. Но это совсем не то же, о чём вы без всяких оговорок заявляли ранее.

>>Rust решает эту проблему другим путём — через типы
>Если я вам говорю, что не решает, не спорьте со мной, я прав. https://doc.rust-lang.org/std/boxed/struct.Box.html#method.t...

Какой-то аноним с Опеннета что-то там говорит. Вы не слишком много на себя берёте предлагая подобные вещи? Перечитайте ваше сообщение и мой ответ ещё раз, до просветления (как вы изволили выражаться). То, что вы приводите - какой-то частный случай, который, вероятно, кому-то нужен, но без которого, по всей видимости, вполне можно обойтись (что наглядно демонстрируют уже существующие программные продукты). Ну и да, раз это есть в ночной сборке, через какое-то время появится в проде. В чём проблема, собственно? "Не сразу Москва строилась", - народная мудрость.

> Паника не имеет ни малейшего отношения к абстракциям нулевой стоимости.

Сама по себе - нет, не имеет. Но вы что-то там об арифметических типах говорили. Вам знакомы языки, где они реализованы, и где нет рантайма? А Rust рантайм не нужен, потому что абстракции с нулевой стоимостью - это то, к чему стремились создатели языка. В противном случае (наличие алгебраических типов) абстракции, скорее всего, перестали бы быть нулевыми.


Остальное не распарсил. Что сказать-то хотели? Ещё раз повторю, я - не телепат, и ваши мысли читать не способен.


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

111. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Прохожий (??), 29-Июн-26, 00:14 
арифметических -> алгебраических (опечатка)
Ответить | Правка | Наверх | Cообщить модератору

113. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (113), 29-Июн-26, 01:43 
>Result и Option — это монады.

А то я не знаю. Если вы не заметили, я вам даже ссылочку на метод скинул.
>Память "течёт" НЕ ТОЛЬКО по этой причине

Так ведь это только подтверждает мою правоту. Rust никак не препятствует утечкам памяти, даже в самых тривиальных случаях.
>а ATS по сложности освоения хуже Rust.

Этот вопрос не делает язык хуже.
>Зачем тогда умолчали об этом?

Затем, что лучшее враг хорошего. Любой язык, который хорош, является барьером для распространения языка, который лучше. Условный бейсик, в котором нужно указывать номера строк - давным давно не используется. Си - хороший язык, идёт 2026 год, и кучу кода пишут на си, то же ядро. Rust это тоже хороший язык, будет идти условный 2046 год, и на расте продолжат писать точно так же, как сейчас пишут на си. Движение вперёд остановится.
>А как динамические массивы связаны с зависимыми типами, которые в Rust отсутствуют?

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

Совершенно верно, в данном конкретном случае. А в случае чего, будет паника, прямо как в питоне, где ошибка в имени переменной будет не во время компиляции(которой нет), а во время исполнения.
>То, что вы приводите - какой-то частный случай

Так в этом то и вопрос. Rust покрывает несколько распространённых случаев, вместо того, чтобы решить всё и сразу.
>который, вероятно, кому-то нужен

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

Кто мешал сразу сделать нормально?
>В чём проблема, собственно?

Я писал об этом выше
>Но конечно же, в каждой из 100500 библиотек этого не будет.

Вы явно не понимаете в чём проблема. Если я хочу обработку данной ситуации, то я не могу взять любую библиотеку с crates, поскольку там, банально, нет данного обработчика. И не будет, даже если прямо сейчас зарелизят это api. Мне как минимум нужно будет форкать библиотеку, со всеми её зависимостями.
>Но вы что-то там об арифметических типах говорили.

А вы - молодец, не смогли их правильно написать, хотя могли бы прокрутить сообщение чуть выше, и посмотреть как правильно.
>В противном случае (наличие алгебраических типов) абстракции, скорее всего, перестали бы быть нулевыми.

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

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

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

120. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (120), 29-Июн-26, 18:04 
Про утечки памяти не правда. В раст логические утечки памяти. Например, если вы в комнату добавляете вещи с ручками, то в раст утечка - это вы забываете их из комнаты выносить или удалять. В то время как в С/С++ вы просто удаляете ручки у вещей, а сами вещи становятся невидимыми. С точки зрения пользователя в комнате уменьшается пространство, и ему все равно почему так получается, но в отличии от раст, где можно посмотреть какая структура программы заняла всю память и быстро выявить причину, в С/С++ придется помучиться, так как весь твой код не имеет больше доступа к вещам, и потому не видит их, а только видит что места мало стало.
Что касается предлагаемого решения, линейные типы усложнят синтаксис но проблему от этого не решат. Программиста это просто заставит писать условия удаления объекта на каждом бранче после создания этого объекта. Но всё равно, таким же образом объект можно "потерять" положив его "во вне", например в глобальный Vec вашего контекста.
На все ответить не смогу, но это как обычно вопрос приоритетов и баланса. Если всё туда впихнуть то получится Emacs. Вместо полного ответа я просто оставлю это тут, и вы сами посмотрите откуда у языка популярность: https://old.reddit.com/r/rust/comments/2581s5/informal_surve.../
rust это язык от народа для народа
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

68. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –2 +/–
Сообщение от Cooler (??), 27-Июн-26, 10:29 
>int + int = undefined behavior.

Ну по вашему, после этого 👆, стоит отменить все программы на Си?
Повторю ещё раз - UB будет только при переполнении. Тут варианта два - либо компилятор должен вставить проверки, чтобы не было UB (это минус к performance, хотя нужно не всегда). Либо программер должен делать проверки. Си пытается быть максимаксимально быстрым. Если нужно избежать UB делайте это непосредственно в программе, если небольшая потеря скорости не критична.

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

71. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (-), 27-Июн-26, 11:26 
> Ну по вашему, после этого 👆, стоит отменить все программы на Си?

А кто говорит про "отмену"?
Просто замена, как "навоз и солому" заменили на кирпич, а потом на железобетон. Хотя обе технологии гораздо сложнее.

> Повторю ещё раз - UB будет только при переполнении.

Да, но UB может случиться при любом сложении не константных int переменных.

И не только. В С99 есть еще ~190 вариантов UB, каждый из которых позволяет отстрелить ногу.

> Тут варианта два - либо компилятор должен вставить проверки, чтобы не было UB (это минус к performance, хотя нужно не всегда).

Тут тоже два варианта: вставлять проверки по умолчанию или нет.

> Либо программер должен делать проверки.

Как мы можем прочитать в новости - не делают)

> Си пытается быть максимаксимально быстрым.

Ценой корректности.
Про что мы можем лицезреть новости на этом сайте буквально каждый день.

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

78. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +2 +/–
Сообщение от Аноним (78), 27-Июн-26, 12:26 
> Повторю ещё раз - UB будет только при переполнении.

Неа. В этом ведь и самя мякотка.
> Либо программер должен делать проверки.

Но далеко не каждый сможет сваять корректную проверку.
Минимальный код для сложения знаковых чисел _по_стандарту_:


#include <limits.h>
 
void f(signed int si_a, signed int si_b) {
  signed int sum;
  if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
      ((si_b < 0) && (si_a < (INT_MIN - si_b)))) {
    /* Handle error */
  } else {
    sum = si_a + si_b;
  }
  /* ... */
}

Насчет совсем не-UBшных граблей из-за int promotion вообще вспоминать не будем:

#include <stdio.h> 
#include <stdlib.h>
int main(int argc, char* argv[]) {
   unsigned char counter = 0xff, 
                 some_val = (unsigned char)(atoi(argv[1]));
   if ((counter + some_val) > counter) {
      printf("%x + %x = %x > %x\n", counter, some_val, counter+some_val, counter);
   }
   return 0; 
}
% gcc -Wall -Wextra hellc.c && ./a.out 10
ff + a = 109 > ff

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

80. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +1 +/–
Сообщение от Ivan_83 (ok), 27-Июн-26, 14:12 
Вот вы упоролись.

1. С никогда не гарантировал ничего относительно типов, оно всё машино зависимое.
Может только float и double тут исключения для которых гарантируется переносимость поведения, но я не вдвалася тк их почти не юзаю.

2. https://github.com/rozhuk-im/liblcb/blob/master/include/math...
я вот так вот примерно unsigned считал, но то что для вас UB для меня вполне норм.

3. Даже если внезаптно оно начнёт считать по другому - у меня есть селфтест для такого кода, который очень интенсивно гоняет все эти функции, и если там хоть один бит где то не так примет значение оно с 99,999% это определит.

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

81. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (78), 27-Июн-26, 14:34 
> Вот вы упоролись.
> 1. С никогда не гарантировал ничего относительно типов, оно всё машино зависимое.

Конечно-конечно. Целый вагон и маленькая тележка машин, где вообще никак не сигнализируется переполнение (и как следствие, всякие __builtin_add_overflow в виде допю расширения во всех мейнстримных копмиляторах - просто от нечего делать) ... угу.

> 2. https://github.com/rozhuk-im/liblcb/blob/master/include/math...
> я вот так вот примерно unsigned считал, но то что для вас UB для меня вполне норм.

Все в лучших традициях "и так сойдет" и "лисапед с почти круглыми колесами и рулем сзади? зато своей постройки!". Куда уж без них. А потом кучам CVE удивляются ...


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

90. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (90), 27-Июн-26, 17:52 
> Конечно-конечно. Целый вагон и маленькая тележка машин, где вообще никак не сигнализируется переполнение (и как следствие, всякие __builtin_add_overflow в виде допю расширения во всех мейнстримных копмиляторах - просто от нечего делать) ... угу.

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

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

92. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –1 +/–
Сообщение от Ivan_83 (ok), 27-Июн-26, 18:07 
> Целый вагон и маленькая тележка машин, где вообще никак не сигнализируется переполнение

Так я про это и написал.
Вы всё никак понять не можете что язык не обязывает делать какие то вещи каким либо определённым образом.


> Все в лучших традициях "и так сойдет" и "лисапед с почти круглыми колесами и рулем сзади?

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

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

93. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (78), 27-Июн-26, 19:04 
>> Все в лучших традициях "и так сойдет" и "лисапед с почти круглыми колесами и рулем сзади?
> Так напишите лучше, я вас не заставляю это использовать. А мы потом посмеямся как у вас ничего не получилось или как оно знатно тормозит.

Самомнение конечно знатное:
https://gmplib.org/
Можете запостить бенчи, насколько ваш шЫдевр обгоняет сию жалкую поделку по скорости ... а заодно по фичам, протестированности, поддержке платформ и т.д. и т.п.

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

97. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 27-Июн-26, 22:45 
А GMP уже переписали на расте?
И у меня математика - это нижний уровень, писалось это для ECDSA/GOST (DSA).
Ответить | Правка | Наверх | Cообщить модератору

106. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Cooler (??), 28-Июн-26, 14:53 
>Неа. В этом ведь и самя мякотка.

Можно пример?

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

107. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –1 +/–
Сообщение от Cooler (??), 28-Июн-26, 14:57 
Никто не складывает абстрактные инты. Как правило у них есть размерность физической величины. Именно это накладывает ограничение на диапазон значений. Если это экранные координаты в пикселях, то вряд ли вы вылезете за 32 бита. Если это вес живого существа в килограммах, то вам и 16 бит будет достаточно. И т.д. и т.п.
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

112. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Прохожий (??), 29-Июн-26, 00:18 
А если это счётчик в каком-то массиве?
Ответить | Правка | Наверх | Cообщить модератору

114. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (113), 29-Июн-26, 01:52 
Ваше рассуждение сугубо порочно. Если речь идёт о компьютерной игре, то игроку будет обидно, если игра без предупреждения заглючит. Если речь идёт о чём-то более серьёзном, например, Therac-25, то это и убить может.
Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

16. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +1 +/–
Сообщение от Аноним (14), 27-Июн-26, 04:11 
Ну если output не в /dev/null, то проблема будет с тем, что это просто слоп. В лучшем случае кое-как работающий.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

103. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (8), 28-Июн-26, 03:07 
>А зачем делать это часто?

Это нужно делать не просто часто, это нужно делать после каждого коммита. А то вдруг моссад/цру/кпк уязвимость решил добавить.
>А в процессе мне хватает -Wall (и ещё пары подобных флагов).

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

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

115. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 29-Июн-26, 08:37 
За правильность граничных случаев сложения отвечает программист а не С.
Ответить | Правка | Наверх | Cообщить модератору

98. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Прохожий (??), 27-Июн-26, 23:05 
Кто прошёлся? Корпы с огромной кучей денег? Почему вы уверены, что так и дальше будет продолжаться? А, главное, почему вы думаете, что это разумно, даже если у них деньги есть для оплаты дорогущей LLM?

Куда практичней было бы переписать всё потихоньку на ЯП, не требующий присутствия LLM, и работающий СТАБИЛЬНО (в отличие от LLM, чей результат не всегда предсказуем в силу природы LLM) - тот же Rust вполне подходит для этих целей сегодня.

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

116. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 29-Июн-26, 12:56 
Раст ни для чего не подходит.
AI не только ошибки в коде ищет как примитивный анализатор или как раст, он ещё подсказывает то что сделано не так, но ошибкой в прямом смысле не является.

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

Чтобы юзать AI много денег не надо, у меня оно и на домашнем компе запускается. Работает не быстро и анализ последних небольших проектов делало 4-8 часов на каждой модели.
Вполне приемлемо.

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

18. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +2 +/–
Сообщение от 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).

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

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

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

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

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

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

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

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

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

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

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

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

39. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от q (ok), 27-Июн-26, 06:14 
> Это всё решается на архитектурном уровне

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

63. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 27-Июн-26, 09:51 
Раст сам весь костыль относительно тех кто не умеет в архитектуру но хочет быть "системным пограмистом, как те крутые деды".


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

Одного без другого не бывает.


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

PHP, Visual basic и прочие языки вам в помощь, только не путайтесь под ногами и не портите чужие проекты и даже уже экосистемы (это я про питон).


> Ты предлагаешь использовать ИИ ВМЕСТО стат. анализаторов.

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

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

99. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  –1 +/–
Сообщение от Прохожий (??), 27-Июн-26, 23:15 
> Раст сам весь костыль относительно тех кто не умеет в архитектуру но хочет быть "системным пограмистом, как те крутые деды".

Это та самая архитектура, после которой CVE ловят 20 лет, и никак выловить не могут? Действительно, "крутые диды". Таких багов понаделали, что до сих пор расхлёбывать приходится.

>> Архитектура не решает вопросов ownership. Это уже уровень проектирования.
>Одного без другого не бывает.

Бывает, конечно. Программы на Си - яркое тому доказательство. Архитектура есть, а с  ownership уже никак.

>>В обоих случаях оба пишут memory-safe код, что и было изначальной задумкой.
>PHP, Visual basic и прочие языки вам в помощь, только не путайтесь под ногами и не портите чужие проекты и даже уже экосистемы (это я про питон).

Вон, даже Линус уже начал говорить о полноценном внедрении Rust в ядро, чтобы молодёжь в проект привлекать. Я к тому, кто здесь ещё под ногами путается в итоге.

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

118. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 29-Июн-26, 12:59 
Линуса троли настрапонили и он решил не доводить дело до состояния Столмана.

У вас постоянно ошибка выжившего: вы не знаете сколько есть проектов без ошибок - в новостях о них ничего не пишут.

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

101. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +1 +/–
Сообщение от Аноним (8), 28-Июн-26, 00:01 
>после того как в компилятор все варнинги повключаешь.

Так они не работают. Вот вам пример
$ cat b.h
struct A {
        int** p;
};

void set_null(struct A*, int**);
int print(struct A*);
$ cat b.c
#include "b.h"

void set_null(struct A* a, int** p)
{
        a->p = p;
}

int print(struct A* a)
{
        int** x = a->p;
        return **x;
}
$ cat a.c
#include <stdio.h>
#include "b.h"

int main()
{
    int y = 7, x = 8;
    int* p_y = &y;
    int* arr[] = {&y, NULL, &x};
    struct A a = {.p = &p_y };
    printf("%d\n", print(&a));
    set_null(&a, arr);
    int num, ret;
    printf("Press 1 and press Enter\n");
    ret = scanf("%d", &num);
    //num = 1;
    arr[0] = arr[num];
    printf("%d", print(&a));
    return 0;
}
$ gcc -flto -fanalyzer b.c -c -o b.o && gcc -flto -fanalyzer a.c -c -o a.o && gcc -fanalyzer a.o b.o -o a && ./a
7
Press 1 and press Enter
1
Segmentation fault         (образ памяти сброшен на диск) ./a
$
---
int test(int* x)
{
    return *x;
}

int main()
{
    int *x = NULL;
    return test(x);
}
gcc -Wnull-dereference c.c

У gcc есть целых два флага, и оба этих флага, совершенно ВНЕЗАПНО не работают.

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

117. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 29-Июн-26, 12:57 
Вам не компилятор нужен а мамка.

Проверять валидность указателей - забота С програмиста, если вас такое не устраивает - велкам в языки без указателей.

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

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

58. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +2 +/–
Сообщение от Tron is Whistling (?), 27-Июн-26, 08:52 
В этом вся проблема всей этой хайпорастии с нейросетями.

Матричная сеть в виде LLM очень хорошо умеет только одно: вводить в заблуждение, выдавая правдоподобный результат, к сожалению, неполный и ошибочный by design, но так, что это несведущему не заметно.

К счастью это уже начинают понимать.

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

Это уже далеко не лошадь vs автомобиль. Это вместо автомобиля дать планер с движком на педальном приводе. Вроде и лучше автомобиля - летает, но как-то печально, и падает сам по себе, и педали крутить за*.

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

79. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +1 +/–
Сообщение от Аноним (79), 27-Июн-26, 14:10 
> Матричная сеть в виде LLM очень хорошо умеет только одно: вводить в заблуждение, выдавая правдоподобный результат, к сожалению, неполный и ошибочный by design, но так, что это несведущему не заметно.

Т.е ошибки нет, ИИшка все наврала и тонны ошибок от мясных Dirty Fag'ов это просто заговор?
Я все правильно понял?

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

Странно, LLM может только вводить в заблуждение, а хитрые дыры (которые не нашли человеки) - находит.

> Но во-первых и здесь возможности не бесконечны

Ой, типа у человеков они бесконечные.

> Во-вторых, исправить эти цепочки корректно нейросеть не может, слишком сложно.

А ей давали такую задачу?

> А кожаные мешки сами по себе эти дыры почти не находили.

Пруфы будут?
Часть проблем очень похожа на бекдор (ну не могут же Лучше СИшники так ошибаться).

> Теперь надо срочно всё исправлять там, где было не надо.

Ай-ай-ай, годами овнокодили, а теперь злая нейронка заставляет исправть! Какой ужас!
Срочно запретить нейронки!!

>  Т.е. вместо уменьшения работы для мешков в итоге получили увеличение.

А у нас KPI это кол-во работы? А чего не усталость))?
Я наивно думал, что мерило кода - это как минимум его корректность и работоспособность, а вон оно чё, михалыч.

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

88. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Tron is Whistling (?), 27-Июн-26, 16:47 
> Странно, LLM может только вводить в заблуждение, а хитрые дыры (которые не
> нашли человеки) - находит.

Ты путаешь кислое с мягким, но тебе позволительно. Именно по этой причине LLM тебе и кажутся умнее.

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

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

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

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

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

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

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

Rust+AI > Rust > C+AI > C

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

46. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от 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ообщить модератору

59. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 27-Июн-26, 08:57 
> В сишных же тебе надо идти уговаривать авторов

Так свобода выбора.
В расте тоже помжно unsafe на весь исходник сделать и не парится.


> CVE, которые идут из-за отсутствия ownership-проверок в сишечке.

Не замечал.
Как написали - так и работает.


> ТЫ не включишь -Werror,

Не совсем.
На работе включил - потому что достали в лог сборки не смотреть.
Мне то хватает -Wall, я лог сборки читаю в отличии от.


> Именно благодаря им пишется memory-safe код.

Который не стоит потраченного на проверки электричетсва пока исполнятся он будет на системах без ЕСС.


> Нормальные люди -- включают всегда.

Обычно таких называют мазохистами.

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


> "кодить быстро" принято в скриптовых языках, а не в системных

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

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

shell script удобен когда уже есть какие то утилиты и надо построить из них пайп для обработки и довесить минимум логики.

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

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

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

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

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

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

57. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Tron is Whistling (?), 27-Июн-26, 08:44 
Пока что все результаты от т.н. "AI" - временные, деструктивные и не окупаемые.
Даже рыночек уже начал сомневаться.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

72. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 27-Июн-26, 11:35 
Хз что значит временные, деструктивность зависит исключительно от оператора ИИ, окупаемые - тут да, крайне не понятно и сомнительно.
Однако даже гугловый бесплатный в поиске экономит кучу времени и сил, лично мне.
Ответить | Правка | Наверх | Cообщить модератору

89. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Tron is Whistling (?), 27-Июн-26, 16:48 
> Однако даже гугловый бесплатный в поиске экономит кучу времени и сил, лично
> мне.

Везёт. Я его вообще отключаю, потому что он лепит полнейший булшит, проще самому быстро пробежать.

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

35. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +1 +/–
Сообщение от Аноним (35), 27-Июн-26, 05:48 
> раст не нужен

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

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

73. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (73), 27-Июн-26, 11:36 
>  Frama C,  

А можно примеры использования?
Пока мы читаем про дыры в ведре и там такими клевыми (возможно) вещами даже не пахнет.

> SPARK

При этом ADA сами в сравнии пишут, что спарк требует изменения методологии.
adacore.com/blog/should-i-choose-ada-spark-or-rust-over-c-c

Что забавно adacore - серебрянный спонсор раста. Наверное они что-то значют))

> Isabelle, Rocq

И как они помогут? Особенно если у тебя миллионы строк кода?

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

85. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (35), 27-Июн-26, 15:38 
> А можно примеры использования?
> Пока мы читаем про дыры в ведре и там такими клевыми (возможно) вещами даже не пахнет.

Гуглим Frama C use cases

> При этом ADA сами в сравнии пишут, что спарк требует изменения методологии.
> adacore.com/blog/should-i-choose-ada-spark-or-rust-over-c-c
> Что забавно adacore - серебрянный спонсор раста. Наверное они что-то значют))

Разумеется требует, это про "надо думать", о котором я говорил. Потому что SPARK - это не только про memory safety, но и про другие виды безопасности. А вообще забавно, как ты сразу увидел "недостаток" SPARK в статье, а недостатки Раста проигнорировал. Вся суть растоманов.

> И как они помогут? Особенно если у тебя миллионы строк кода?

Как поможет раст, особенно если у тебя миллионы строк кода?

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

105. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Пыщь (?), 28-Июн-26, 09:58 
Интересно, из вас 2-их кто-нибудь пробовал написать на SPARK хелловрот с плюшками распараллеливаия и прочим суперкешем, но со всеми требованиями бензоопасТности?
Ребята из adacore тоже не истина в последней инстанции, их GNATstudio не отличается высоким качеством "илитных" погроммистов. Кто платит девушку - тот и танцует, ну не может быть у них независимого мнения.
Большущее имхо.
Ответить | Правка | Наверх | Cообщить модератору

56. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Tron is Whistling (?), 27-Июн-26, 08:41 
Вот как раз в анализ существующего оно и может.

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

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

17. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (17), 27-Июн-26, 04:12 
user namespace - источник дыр.

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

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

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

47. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +1 +/–
Сообщение от Аноним (17), 27-Июн-26, 07:40 
В io_uring регулярно дыры находят, вроде.
Ответить | Правка | Наверх | Cообщить модератору

60. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (60), 27-Июн-26, 09:12 
site:opennet.ru io_uring
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

54. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 27-Июн-26, 08:38 
А как же chroot?
Ещё виртуализация есть.
Ответить | Правка | Наверх | Cообщить модератору

65. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +1 +/–
Сообщение от Аноним (1), 27-Июн-26, 10:10 
Chroot не изолирует ядро, Мань. Вообще ничего не изолирует на самом деле. Виртуализация открывает кучу векторов с дырявыми устройствами -- к ядру добраться проще, чем из неймспейсов.
Ответить | Правка | Наверх | Cообщить модератору

74. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 27-Июн-26, 11:38 
Так и неймспейсы ядро не изолируют.
Виртуализацию можно по разному настроить.
Ответить | Правка | Наверх | Cообщить модератору

87. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (1), 27-Июн-26, 15:57 
Неймспейсы изолируют различную функциональность ядра, в неймспейсе делай что хочешь -- хосту не помешаешь. Если у тебя нет рута в неймспейсе, ты не сделаешь ничего в принципе вне неймспейса. И если есть, с ограничениями некоторые операции виртуального рута позволены даже если на самом деле только права пользователя. У пользователя есть право замапить рута в неймспейс не имея рута на хосте, это источник ряда уязвимостей, но это необходимо определённому софту.

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

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

104. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (8), 28-Июн-26, 03:09 
>Виртуализацию можно по разному настроить.

Виртуализация очень серьёзно увеличивает потребление ресурсов.

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

119. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Ivan_83 (ok), 29-Июн-26, 13:02 
Мне тут расказывали что магический линукс в виртуалке умеет дедупликацию памяти делать, так что оверхэд получается минимальным.

Потом смотря что виртуализировать: если вы пинг в виртуалку засуните то да, оверхэд огромный, а если у вас в вируалке какая то llamacpp на 200+гб памяти то там того оверхэда и не найти с лупой.

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

66. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (1), 27-Июн-26, 10:20 
Ну и потом, неймспейсы это изоляция уровня приложения. К примеру, процессу, крутящему шейдеры, ни к чему доступ в сеть.
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

102. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (8), 28-Июн-26, 03:03 
>Хотел было порекомендовать простой фикс для всех проблем с pagecache: флюшить/не использовать для setuid процессов, но там же начнут passwd и прочие файлы так же "перезаписывать"...

А вы - молодец, даёте советы, абсурд которых сами же понимаете.
>Но как обычно почти всё сводится: не включай неймспейсы...

И не включай компьютер, да ведь?

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

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

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

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

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

64. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (64), 27-Июн-26, 09:57 
В каждом линуксе есть уязвимость, позволяющяя непривилегированному пользователю получить права root через ввод правильного пароля в su.
Ответить | Правка | Наверх | Cообщить модератору

84. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (83), 27-Июн-26, 15:16 
Та уязвимость не в ядре, несчитово.
Ответить | Правка | Наверх | Cообщить модератору

70. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (70), 27-Июн-26, 10:59 
Suid зло, а модель, на нем основанная, устарела лет 20 назад
Ответить | Правка | Наверх | Cообщить модератору

109. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от devrdskc0t0d0s1 (-), 29-Июн-26, 00:00 
Надо микроядра развивать, а не стильные, модные, молодёжные вещи туда-сюда дёргать. Но безопасность не выгодна компаниям и гос-ву.
Ответить | Правка | Наверх | Cообщить модератору

76. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (76), 27-Июн-26, 12:03 
Ядро 6.18.31 без iptables вроде мимо.
Жду новых уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору

82. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от bublick (ok), 27-Июн-26, 14:55 
Интересно почему "начиная с ядра Linux 5.18", а раньше нет?
Ответить | Правка | Наверх | Cообщить модератору

108. "PEdit-CoW и DirtyClone - уязвимости в ядре Linux, позволяющи..."  +/–
Сообщение от Аноним (6), 28-Июн-26, 18:21 
потому что в этой версии создали данную уязвимость
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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