forum.opennet.ru - "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять свои привилегии в системе" (100)

"Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять свои привилегии в системе"

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

"Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять свои привилегии в системе"	+/–
Сообщение от opennews (??), 12-Апр-23, 13:52
В ядре Linux выявлены две уязвимости (CVE-2023-1281, CVE-2023-1829), позволяющие локальному пользователю поднять свои привилегии в системе. Для проведения атаки требуются полномочия на создание и изменение классификаторов трафика, доступные при наличии прав CAP_NET_ADMIN, которые можно получить при возможности создания пространств имён идентификаторов пользователя (user namespace). Проблемы проявляются начиная с ядра 4.14 и устранены в ветке 6.2... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58955
Ответить \| Правка \| Cообщить модератору

Оглавление

Скрыто модератором, Denys (??), 13:57 , 12-Апр-23, (2)

Скрыто модератором, Вы забыли заполнить поле Name (?), 20:34 , 13-Апр-23, (151)

Что-то этот ваш user namespace какой-то перфорированный всё время , Аноним (3), 14:01 , 12-Апр-23, (3) +9

Это кого надо спейс И они его доят , Аноним (10), 14:12 , 12-Апр-23, (10) +2

Можно подумать это специально Ядро не делали с учетом таких вещей, изначально с, Аноним (-), 09:07 , 13-Апр-23, (130) +1

Слишком вкусная фича, чтобы от нее отказываться , Аноним (18), 14:41 , 12-Апр-23, (18)
ну так что ты хочешь от механизма дающего юзеру рута но не вот совсем совсем а т, пох. (?), 17:02 , 12-Апр-23, (72) +2
Спасибо дидам с их офигенными идеями про привилегированные порты В семидесятые , Аноним (94), 18:23 , 12-Апр-23, (94) –2

А при чем тут привилегированные порты В уязвимости ни слова про это, там какие-, Аноним (-), 09:01 , 13-Апр-23, (128)

Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN Ну не для, Аноним (94), 17:43 , 13-Апр-23, (148) –1

Чтобы настраивать сеть на своем компе например То-есть, там свои сетевые ин, Аноним (-), 18:54 , 13-Апр-23, (150)

Это типа про звон Причём тут порты Тут как раз про любимые контейнеры , 1 (??), 09:04 , 13-Апр-23, (129)

Зачем тебе контейнеры и почему чрута не хватает Ага, то-то же , Аноним (94), 17:43 , 13-Апр-23, (149)

И опять use-after-free , marten (ok), 14:08 , 12-Апр-23, (5)

ваши предложения , Аноним (10), 14:10 , 12-Апр-23, (6)

Очевидно же -- free должна портить память Либо скорость, либо безопасность , Rock (?), 14:47 , 12-Апр-23, (19)

насколько это free ptr быстрее, чем это free ptr ptr NULL , Аноним (18), 16:40 , 12-Апр-23, (66)

Незаметно Удивительно, что дизайнеры C POSIX API не сделали так, чтобы этот NULL, Аноним (67), 16:52 , 12-Апр-23, (67) +2

ты можешь написать макрос, который будет вызывать free и обнулять переменную , Аноним (18), 17:13 , 12-Апр-23, (76) +1

Вот, только каждый программист напишет своих подобных костылей с разными названи, InuYasha (??), 17:37 , 12-Апр-23, (79) +1

это лучше, чем заставлять free возвращать что-то там, хотя на самом деле ему воз, Аноним (18), 17:54 , 12-Апр-23, (84)

По мне - так любая функция должна возвращать если не HRESULT, то хоть bool succe, InuYasha (??), 18:55 , 12-Апр-23, (98) –1

И, да, я знаю про try - throw - catch, но оно дико стрёмное , InuYasha (??), 18:56 , 12-Апр-23, (99)

В сях вообще нет этих понятий Да и вон то далеко не везде катит , Аноним (157), 09:14 , 14-Апр-23, (157)

А в случае неуспешного освобождения что будет возвращать free , n00by (ok), 07:27 , 13-Апр-23, (123)

Неуспешное освобождение памяти - это что Как на чисто логическом уровне это мо, Аноним (-), 09:14 , 13-Апр-23, (131)

Это ситуация, обратная успешному освобождению См 8470 67, на которое я отвеча, n00by (ok), 10:10 , 13-Апр-23, (140)

В вон том определении реализации функции просто нет места call fails - либо вс, Аноним (-), 12:35 , 13-Апр-23, (142)

call fails входит в множество UB Если что, я знаю, что ты любишь высказывать м, n00by (ok), 13:17 , 13-Апр-23, (146)

Call fails - как раз обычно well defined behavior, как именно проверить не успе, Аноним (-), 22:07 , 13-Апр-23, (152)

Я уже понял, что операции над множествами - не твоё Не требуется дальше убеждать, n00by (ok), 08:46 , 14-Апр-23, (156)
А у вас проблемы с логическими операциями Для меня выглядит так как будто это Л, Аноним (157), 09:30 , 14-Апр-23, (158)
Это не имеет отношения к UB и твоему непониманию, что такое UB , n00by (ok), 09:46 , 14-Апр-23, (159)
По-моему самое непосредственное отношение Либо поведение определено и подлежит, Аноним (157), 11:27 , 14-Апр-23, (161)
3 4 31 undefined behaviorbehavior, upon use of a nonportable or erroneous progra, n00by (ok), 15:03 , 14-Апр-23, (163)
Для функции free в стандарте ничего не сказано про то что эта операция вообще , Аноним (166), 23:58 , 20-Апр-23, (166)
Всё там сказано, читайте цитаты в моих сообщениях, начиная с 8470 140 Или учи, n00by (ok), 07:01 , 21-Апр-23, (167)

Ну, вот, как порча указателя на память связана с порчей памяти Речь шла о том, , Rock (?), 20:17 , 18-Апр-23, (165)

Скрыто модератором, Анонимусс (?), 14:49 , 12-Апр-23, (20) +1
собирать мусор 30 минут, как в джаваскрипте, Аноним (21), 14:51 , 12-Апр-23, (21) +1

В JS V8,JavaScriptCore довольно быстрый сборщик мусора - в отличие от сишного , Аноним (102), 19:19 , 12-Апр-23, (102) –1

джаваскрипт легендарен своей текущей jvm, учи матчасть, Аноним (21), 07:07 , 13-Апр-23, (121)
Угу, именно поэтому при потугах что-то активно делать все тормозит а браузер жре, Аноним (-), 09:18 , 13-Апр-23, (132)

да они не понимают, что такие ситуации можно отследить только контролем за каждо, FF (?), 15:25 , 12-Апр-23, (37) –3
Уже много раз повторялось - прикрутите вы нормальный менеджер памяти типа FastMM, Аноним (77), 17:26 , 12-Апр-23, (77) +1

Для тех кто этого хотел уже давно есть KASAN Enjoy your ride if you can Но п, Аноним (-), 09:19 , 13-Апр-23, (133)

std unique_prt Но это породит новые проблемы, из-за использования двух языков , n00by (ok), 07:35 , 13-Апр-23, (124)

Не ной, сделай чекер, который будет находить такое и исправлять , Иваня (?), 16:58 , 12-Апр-23, (71)

зачем чекер достаточно просто в chatGPT написать - сделай нам хорошо и всё, д, Аноним (74), 17:04 , 12-Апр-23, (74)

fixОпять дырявая x86 , анон (?), 17:06 , 12-Апр-23, (75)

Ну кстати, -mptr128 на e2k рубит и use-after-free , Michael Shigorin (ok), 20:11 , 12-Апр-23, (105)

Мне кажется адепты это не язык виноват, это программисты ОБЯЗАНЫ фиксить такие, Аноним (22), 14:51 , 12-Апр-23, (22)

Предлагаю сишникам перестать делать use-after-free Это же всего-лишь нужно вызыв, Анонин (?), 15:01 , 12-Апр-23, (26)

Вы даже не поняли смысла use-after-free а что то предлагаете uint8_t ptr ma, Ivan_83 (ok), 15:12 , 12-Апр-23, (31) +2

Когда не выкупают иронию и самый простой юмор это уже старость , Аноним (10), 15:16 , 12-Апр-23, (34) –2

Не вижу юмора в том, что человек путает double-free и use-after-free , Ivan_83 (ok), 16:00 , 12-Апр-23, (54)

Прости чувак, хаскелистам не интересно разбираться в сортах ваших сишных багов Н, Анонин (?), 17:04 , 12-Апр-23, (73) –1

Как и сишникам в сортах функторов и ко про монад Понаделают своего абстрактного, Аноним (119), 02:05 , 13-Апр-23, (119)

Более того - код на хаскеле обычно в результате никто кроме его автора не понима, Аноним (-), 12:38 , 13-Апр-23, (143)

Как там говорится Филин - стратег , Аноним (-), 09:21 , 13-Апр-23, (134)

Привет FreeAndNil из паскаля Так может C не такой уж классный , Аноним (77), 17:28 , 12-Апр-23, (78)

Может стоит научиться отличать Си от Си , n00by (ok), 07:38 , 13-Апр-23, (125) –2

зачем с это надстройка над си, а не какой-нибудь язык, претендующий на незави, Аноним (21), 11:12 , 13-Апр-23, (141)

Что бы не публиковать нижеследующую чепуху , n00by (ok), 13:26 , 13-Апр-23, (147) –1
Вот ведь блин, а ISO не в курсе такой ерунды и выпускает 2 набора стандартов от , Аноним (157), 11:17 , 14-Апр-23, (160)

мне кажется, адепты, которым кто-то чего-то должен, просто не могут достать из л, FF (?), 15:26 , 12-Апр-23, (38) +1

А почему нужно быть должным кому-то Иксперды лучше-всех-написаторы могут быть д, Аноним (22), 15:35 , 12-Апр-23, (45) –1

Адепты язык все исправит вызвались написать свою ОС без этих несчастных C про, Аноним (56), 16:04 , 12-Апр-23, (56) +2

Как будто без этого дырявая система написанная дедами стала менее дырявой А пи, Анонимусс (?), 16:54 , 12-Апр-23, (69)

Как будто с растом что-то изменится , Аноним (10), 18:11 , 12-Апр-23, (90)

Доказать эти сомнения элементарно - приведи пример аналогичного бага в раст коде, Аноним (117), 00:33 , 13-Апр-23, (117)

Вас забанили на сайте с списком CVE Там замечательный ассортимент, есть и ошибк, Аноним (157), 11:32 , 14-Апр-23, (162)

Скрыто модератором, ivan_erohin (?), 09:34 , 13-Апр-23, (139)

Файрфоксу уже исправили, теперь это чудо природы стало стабильно падать раз в эн, Аноним (-), 09:25 , 13-Апр-23, (135) –1

Ядро 4 14 вышло в ноябре 2017 года И никто ничего не заметил Печально , Анонн (?), 15:04 , 12-Апр-23, (28) +2

Ты пишешь под новостью, в которой кто-то что-то все-таки заметил , Аноним (18), 15:06 , 12-Апр-23, (30) +4

Всего-то 6 лет понадобилось чтобы заметить Подумаешь , Rev (?), 15:48 , 12-Апр-23, (48) +2

А в шинды такой же дыре уже 30 лет , Аноним (10), 15:57 , 12-Апр-23, (52) +1

это другое, Аноним (126), 07:50 , 13-Апр-23, (126)

Все видели, кому это надо было Писали руткиты и продавали их, и или получали за, ИмяХ (?), 17:54 , 12-Апр-23, (83) +1

На gentoo в новости две ссылки, и обе на несуществующий CVE, Аноним (44), 15:33 , 12-Апр-23, (44)
Уже было Оказыватся, я уже это делал давно, судя по конфигам , Аноним (57), 16:09 , 12-Апр-23, (57) +1

Кто-то всё знал и молчал пора размотать этот клубок заговоров и лжи , Аноним (10), 16:17 , 12-Апр-23, (59) +2

При том эти заговоры тянутся уже не менее полувека какие-то п сы пишут докуме, Аноним (-), 09:27 , 13-Апр-23, (136)

Если я усну и проснусь через десят лет и меня спросят, что сейчас происходит в с, Анонимусс (?), 16:53 , 12-Апр-23, (68) –3

Правильный ответ будет ничего не происходит , ибо искусственному интеллекту Cи , Аноним (116), 23:10 , 12-Апр-23, (116)

Кто-нить ещё помнит, зачем отключали QoS во времена Win98 Вот, теперь и в, InuYasha (??), 17:39 , 12-Апр-23, (81)

Потому что они хотели чтобы все ушли в NT где всё сделают правильно Вин98 это в, Аноним (10), 18:13 , 12-Апр-23, (92) +1

У меня складывается впечатление, что все DE в linux это Win98 над MS-DOS Я не с, Аноним (108), 21:04 , 12-Апр-23, (108) +1

в чем похожесть , Аноним (126), 07:51 , 13-Апр-23, (127)

Потому, что там от QoS не было толку , Аноним (67), 19:15 , 12-Апр-23, (101)

Я не понял они просто выбросили модуль вместо исправления От трюкачи , Егор (??), 18:39 , 12-Апр-23, (97) –1
Не понимаю тех, кто просит его включить , Michael Shigorin (ok), 20:18 , 12-Апр-23, (106) –3

В Debian 10 этот параметр выключен и тем не менее завели на него статус уязвимо , Аноним (109), 21:43 , 12-Апр-23, (109)

Видимо чтобы трекать поставки фикшеных ядер Ну как, поставлять ядро с известной, Аноним (-), 22:13 , 13-Апр-23, (153)

12-04-2023 20 51 23Gentoo, RHEL, SUSE, Fedora, Gentoo, Arch нет этого CVE в багт, Аноним (108), 20:53 , 12-Апр-23, (107)
Дебиан 9 как всегда торт , Аноним (126), 22:12 , 12-Апр-23, (114)

Скрыто модератором, Аноним (-), 09:29 , 13-Апр-23, (137)
Скрыто модератором, Аноним (-), 12:42 , 13-Апр-23, (145)

Молодцы , Аноним (116), 23:08 , 12-Апр-23, (115)

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

2. Скрыто модератором +/–

Сообщение от Denys (??), 12-Апр-23, 13:57

"обращением к памяти после её освобождения (use-after-free)"
классика С/С++, сколько ещё будет таких уязвимостей?

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

151. Скрыто модератором +/–

Сообщение от Вы забыли заполнить поле Name (?), 13-Апр-23, 20:34

> "обращением к памяти после её освобождения (use-after-free)"
> классика С/С++, сколько ещё будет таких уязвимостей?
В С++ с использованием RAII такого минимум.

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

3. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +9 +/–

Сообщение от Аноним (3), 12-Апр-23, 14:01

Что-то этот ваш "user namespace" какой-то перфорированный всё время.

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

10. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +2 +/–

Сообщение от Аноним (10), 12-Апр-23, 14:12

Это кого надо спейс. И они его доят.

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

130. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от Аноним (-), 13-Апр-23, 09:07

Можно подумать это специально. Ядро не делали с учетом таких вещей, изначально система была одна, контейнеров не было, ядро считало CAP_NET_ADMIN безусловным сигналом к действию. А когда всем захотелось контейнеры, сову совместными усилиями натянули на глобус, оказалось что некоторые нюансы все же есть. Ну вот и штопают периодически, когда ядро рута контейнера за рута всей системы воспринимает. А таких мест в ядре в всяких экзотичных краевых случаях наверняка еще есть.
В обычной системе могли особо и не париться - если рут сам себе отстрелит пятку, он это и так мог, кому хуже то. А тут вот рут мог быть и не настоящий. Опа.

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

18. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (18), 12-Апр-23, 14:41

Слишком вкусная фича, чтобы от нее отказываться.

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

72. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +2 +/–

Сообщение от пох. (?), 12-Апр-23, 17:02

ну так что ты хочешь от механизма дающего юзеру рута но не вот совсем совсем а так... на пол-шишечки?

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

94. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –2 +/–

Сообщение от Аноним (94), 12-Апр-23, 18:23

Спасибо дидам с их офигенными идеями про привилегированные порты. В семидесятые это может быть и была хорошая идея, но уже в начале века было ясно, что от этого костыля надо избавляться. Почему за 20 лет не избавились — загадка.

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

128. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 09:01

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

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

148. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –1 +/–

Сообщение от Аноним (94), 13-Апр-23, 17:43

Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN? Ну не для того же, чтобы слушать «привилегированный» порт? Понятно, что не только для этого, и примеров, когда без неймспейса никак тоже хватает, но основная задача таки тривиальна: слушать на портах <1024 без рута. А то, что всякие обскурные механизмы вроде QoS от такого ломаются то не диво. Диды те ещё программисты локалхоста были, они даже представить себе не могли, что в многопользовательской системе пользователи захотят что-то делать полезное, а не только sedеть и gawkать.

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

150. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 18:54

> Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN? Ну не
> для того же, чтобы слушать «привилегированный» порт?
Чтобы "настраивать сеть" на "своем компе" например. То-есть, там свои сетевые интерфейсы, на которые захочится свои айпишники навесить, со стороны контейнера. И все такое. Если хочется чтобы это выглядело как вот именно отдельный комп с линухом.
Без этого до вон того дело даже и не дойдет, так то. Видел OpenVZ? Это полная версия той идеи. Они это изначально делали какими-то жуткими патчами, дико лагающими относительно майнлайна по скорости их выпуска. За что и скопытились как виртуалки стали быстрыми и эффективными. Но часть этого в майнлайн внесли, а народ фичу в принципе хочет, так что в целом оно все же есть.
> основная задача таки тривиальна: слушать на портах <1024 без рута.
Это в линухе делается и без вон тех прав и namespace, экий вы затейник получать эти возможности такой левой пяткой в правое ухо.
> А то, что всякие обскурные механизмы вроде QoS от такого ломаются то не диво.
И прочие проверки прав и так далее. Но для начала идея в том что контейнер будет типа отдельной машиной, с отдельной сетевой конфигурацией. А чтоб ее настроить пригодится CAP_NET_ADMIN. Он как бы немного виртуальный но, вот, увы, не всегда...
> Диды те ещё программисты локалхоста были, они даже представить
> себе не могли, что
...что из 1 компа и ОС захотят сделать N типа-независимых с минимальным оверхедом. И да, не могли. Как максимум в соляре зоны были. Ну да, пораньше. Но ядро линукса начали кодить тоже не вчара и тогда такое еще не было в ходу вроде.
Это тот случай когда факап на уровне архитектуры, но - увы - при таком размере кодовой базы с ноля рефакторить не вариант, приходится фичу на скотч приделывать. Мир не идеален.

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

129. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от 1 (??), 13-Апр-23, 09:04

Это типа про "звон" ? Причём тут порты ? Тут как раз про любимые контейнеры.

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

149. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (94), 13-Апр-23, 17:43

Зачем тебе контейнеры и почему чрута не хватает? Ага, то-то же.

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

5. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от marten (ok), 12-Апр-23, 14:08

И опять use-after-free...

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

6. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (10), 12-Апр-23, 14:10

...ваши предложения?

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

19. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Rock (?), 12-Апр-23, 14:47

> ...ваши предложения?
Очевидно же -- free должна портить память. Либо скорость, либо безопасность.

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

66. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (18), 12-Апр-23, 16:40

> Либо скорость, либо безопасность
насколько это:
    free(ptr);
быстрее, чем это:
    free(ptr);
    ptr = NULL;
?

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

67. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +2 +/–

Сообщение от Аноним (67), 12-Апр-23, 16:52

Незаметно.
Удивительно, что дизайнеры C/POSIX API не сделали так, чтобы этот NULL возвращала функция free() после успешного освобождения.
ptr = free(ptr);

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

76. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от Аноним (18), 12-Апр-23, 17:13

ты можешь написать макрос, который будет вызывать free() и обнулять переменную. Вызывать так: clear(ptr). Оставлю тебе на дом, каким должен быть #define clear.

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

79. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от InuYasha (??), 12-Апр-23, 17:37

Вот, только каждый программист напишет своих подобных костылей с разными названиями и поведением - и сиди, сходи с ума, изучая всё это. Хотя, даже позикс иногда объявляется устаревшим - что уж там...
PS: только не макрос лучше, а инлайн, наверное.

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

84. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (18), 12-Апр-23, 17:54

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

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

98. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –1 +/–

Сообщение от InuYasha (??), 12-Апр-23, 18:55

По мне - так любая функция должна возвращать если не HRESULT, то хоть bool success. Ну, не glVertex3f, конечно, где прям за каждый такт трясёшься. (да, я знаю! это просто пример!)

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

99. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от InuYasha (??), 12-Апр-23, 18:56

И, да, я знаю про try - throw - catch, но оно дико стрёмное.

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

157. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (157), 14-Апр-23, 09:14

> И, да, я знаю про try - throw - catch, но оно > дико стрёмное.
В сях вообще нет этих понятий. Да и вон то далеко не везде катит.

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

123. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от n00by (ok), 13-Апр-23, 07:27

> Удивительно, что дизайнеры C/POSIX API не сделали так, чтобы этот NULL возвращала
> функция free() после успешного освобождения.
> ptr = free(ptr);
А в случае неуспешного освобождения что будет возвращать free()?

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

131. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 09:14

Неуспешное освобождение памяти - это что?! Как на чисто логическом уровне это могло бы выгдядеть вообще? Потому что в free() такой вариант не присутствует. См man 3 free.
В самых идиотских ситуациях (попытки освободить то что не выделяли или уже освободили) - в спеках на функцию сказано "undefined behavior". В идеале такие вещи следовало бы ловить но видимо трекинг аллокаций и проверка этого при free() достаточно дорого по скорости и оверхеду обходится.

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

140. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от n00by (ok), 13-Апр-23, 10:10

> Неуспешное освобождение памяти - это что?!
Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал.
> Как на чисто логическом уровне это
> могло бы выгдядеть вообще? Потому что в free() такой вариант не
> присутствует. См man 3 free.
ISO/IEC 9899:2017
7.22.3.3 The free function
2 ... if the argument does
not match a pointer earlier returned by a memory management function, or if the space has been
deallocated by a call to free or realloc, the behavior is undefined.
> В самых идиотских ситуациях (попытки освободить то что не выделяли или уже
> освободили) - в спеках на функцию сказано "undefined behavior". В идеале
> такие вещи следовало бы ловить но видимо трекинг аллокаций и проверка
> этого при free() достаточно дорого по скорости и оверхеду обходится.
И что возвращать в этом случае? Если NULL, тогда можно самому занулять указатель, как и предалали. Если не NULL, тогда рац.предожение теряет смысл. Потому и не вижу ничего удивительно в текущей реализации.

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

142. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 12:35

> Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал.
В вон том определении реализации функции просто нет места "call fails" - либо всегда success, либо UB. Если что, UB != call fails.
> deallocated by a call to free or realloc, the behavior is undefined.
Ну и как видите в этом (да, достаточно дурацком) определении не предусмотренно именно "fails". Вместо этого "хз что будет, ваша проблема". И вообще-то это пример того как апи делать не надо. Но в сях у комитета есть мерзкая привычка спихивать свои проблемы на других, чтобы не прописывать конкретику behavir. На мой вкус тут вопрос скорее к стандарту и апи самому по себе. Уж как минимум обязать free вешать null на указатель и чекать при входе в него что дали null и репортить жесткий usage error, вплоть до краха программы, было бы весьма логично (и не так уж дорого по ресурсам). Ядерщики кстати могли бы себе нечто такое и сделать - они стандартами си и тем более фичами libc не зажаты так то и у них много забавного кастома есть.
> И что возвращать в этом случае?
По уму это апи надо переделать, но мы повесимся из за слома совместимости.
> Если NULL, тогда можно самому занулять указатель, как и предалали.
> Если не NULL, тогда рац.предожение теряет смысл. Потому и не вижу ничего
> удивительно в текущей реализации.
Мне вообще вот это апи не особо нравится. Я бы вообще запретил комитетчикам использовать слово "undefined behavior". Ибо нефиг.

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

146. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от n00by (ok), 13-Апр-23, 13:17

>> Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал.
> В вон том определении реализации функции просто нет места "call fails" -
> либо всегда success, либо UB. Если что, UB != call fails.
"call fails" входит в множество UB.
Если что, я знаю, что ты любишь высказывать мнение по вопросам, в коих понимаешь мало.
Я уже просил тебя не тратить моё время и не мешать мне переписываться с другими Анонимами.

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

152. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 22:07

> "call fails" входит в множество UB.
Call fails - как раз обычно well defined behavior, как именно проверить (не)успех операции при этом явно прописывается в документации. Как в манах линукса, on success... returns X, on failure... returns Y and sets errno to 123. И так далее. Для free() идентификация fail его вызова в стандарте не прописана, такого понятия для этой функции в стандарте просто нет.
Если не указана конкретика как проверить call failed, мы не можем узнать что он failed, и это понятие не имеет смысла. А если указано - тогда это уже "defined behavior", никак не UB. И в этом аспекте free() не имеет понятия "call failed" в определении интерфейса. Только некорректное использование, но это другое.
> Если что, я знаю, что ты любишь высказывать мнение по вопросам, в
> коих понимаешь мало.
> Я уже просил тебя не тратить моё время и не мешать мне
> переписываться с другими Анонимами.
Наверное вы меня с кем-то перепутали, не припоминаю такое. Но уровень снобизма в паре с некомпетентностью заценил, так что определенный пойнт в ваших словах все же есть.

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

156. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от n00by (ok), 14-Апр-23, 08:46

>> "call fails" входит в множество UB.
> Call fails - как раз обычно well defined behavior
Я уже понял, что операции над множествами - не твоё.
Не требуется дальше убеждать меня в этом.

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

158. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (157), 14-Апр-23, 09:30

А у вас проблемы с логическими операциями. Для меня выглядит так как будто это ЛИБО undefined behavior, ЛИБО, если понятие call fails определено, тогда рассказано как определить fail, и тогда это уже defined behavior. Вы, кажется, этого не поняли.
Defined behavior отличается от undefined как раз тем что конкретно расписано что и как происходит. Если это расписано для call fails - окей, это defined behavior, мы можем определить это в caller'е. А в вон том случае "call fails" просто не определен как сущность. Этого понятия не существует для этой функции, как минимум в стандарте.
С точки зрения реализации видимо идея была такая что на этот момент все ресурсы которые надо было выделить уже были успешно выделены, новых не надо и как может обломиться чистая математика и маркировка регионов - загадка. Если случилось что-то вообще совсем странное, типа read или write error в каком-нибудь там свопфайле, это уже глубокая и невосстановимая системная ошибка и там разве что SIGSEGV какой процессу прислать, или что там по мнению системы уместно, когда выполнение процесса совсем нельзя возобновить в нужном виде.

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

159. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от n00by (ok), 14-Апр-23, 09:46

> А у вас проблемы с логическими операциями.
Это не имеет отношения к UB и твоему непониманию, что такое UB.

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

161. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (157), 14-Апр-23, 11:27

По-моему самое непосредственное отношение. Либо поведение определено (и подлежит документированию), либо нет. Это бинарная величина. Для free() не определено понятие фэйла при легитимном использовани, его просто нет. Если понятия нет, оно не может входить в какое либо множество.
При нормальном использовании в пределах спеков видимо считается что он всегда успешен, там нет места для fails в результатах вызова, стало быть это понятие просто не существует в этих абстракциях. Это скорее из категории "should never happen".
И на самом деле это как раз ключевая грабля стандартов на си и их стдлиб, там очень много чего недоопределено, определено неоднозначно или допускает UB. И за это временами тех господ из ISO хочется немножечко придушить.

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

163. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от n00by (ok), 14-Апр-23, 15:03

3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which
this International Standard imposes no requirements
поведение ... к которому не предъявляется (никаких) требований.
Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".
2 Note 1 to entry: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results,
***to behaving during translation or program execution in a documented manner*** characteristic of the environment (with or
without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic
message).
и разрешено документировать поведение, что как раз и оправдано в ядре.

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

166. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (166), 20-Апр-23, 23:58

> Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".
Для функции "free" в стандарте ничего не сказано про то что эта операция вообще может обломаться. С таким же успехом можно предположить что имелось в виду что это - "should never happen", а если все же happen это баг имплементации.
> 2 Note 1 to entry: Possible undefined behavior ranges from ignoring the
> situation completely with unpredictable results,
Маленький нюанс в том что в доке описывающей free() про UB вообще совсем ничего не упомянуто. То-есть не специфицировано что оно может обломаться и что при этом будет UB. Это вы сами от себя додумали. Откуда это следует я не знаю.
Как более жесткий пример: если я вызываю void something(void) - тут прямо на уровне прототипа прозрачный намек что оно не обламывается, и с таким прототипом как правило предполагается что оно всегда успешно - например, в чистой математике нечему обламываться. И в освобождении памяти в его изначальном понимании тоже: все ресурсы на этот момент уже выделены а новых выделять не надо.
> и разрешено документировать поведение, что как раз и оправдано в ядре.
Ну вот в ядре могли бы и сделать зануление указателей и жесткий завал если null на входе оказался. Там местами некая смежная активность есть, скажем они научились в зануление памяти при alloc/free оного (выбираемо для каждого из) - это тоже так то полезно для безопасности и утечек информации.
Может не особо парятся потому что кому сильно надо KASAN всякие использовали при пуске на этом syzbot и тому подобных штук.

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

167. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от n00by (ok), 21-Апр-23, 07:01

>> Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".
> Для функции "free" в стандарте ничего не сказано про то что эта
> операция вообще может обломаться.
Всё там сказано, читайте цитаты в моих сообщениях, начиная с №140. Или учитесь их понимать, если уже читали.

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

165. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Rock (?), 18-Апр-23, 20:17

>> Либо скорость, либо безопасность
> насколько это:
>     free(ptr);
> быстрее, чем это:
>     free(ptr);
>     ptr = NULL;
> ?
Ну, вот, как порча указателя на память связана с порчей памяти? Речь шла о том, что free могла бы обнулять память ради безопасности. Очевидно, что повлиять на указатели на эту память, сохраненные где-то снаружи, она чисто технически никак не может.
Я вообще не понимаю людей на этом форуме...

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

20. Скрыто модератором +1 +/–

Сообщение от Анонимусс (?), 12-Апр-23, 14:49

Предлагаю сишникам наконец-то перестать портить память!

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

21. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от Аноним (21), 12-Апр-23, 14:51

собирать мусор 30 минут, как в джаваскрипте

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

102. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –1 +/–

Сообщение от Аноним (102), 12-Апр-23, 19:19

В JS (V8,JavaScriptCore) довольно быстрый сборщик мусора - в отличие от сишного дидовского кода, где memory-leak-мусор по всей системе и убирать его не спешат.

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

121. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (21), 13-Апр-23, 07:07

джаваскрипт легендарен своей текущей jvm, учи матчасть

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

132. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 09:18

> В JS (V8,JavaScriptCore) довольно быстрый сборщик мусора -
Угу, именно поэтому при потугах что-то активно делать все тормозит а браузер жрет гигазы оперативы. Достаточно посмотреть как работают например игровые движки, это достаточно здоровые штуки чтобы хотеть именно постоянную аллокацию-деаллокацию, т.к. держать в памяти всообще все ассеты более-менее приличной гамезы малореально.

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

37. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –3 +/–

Сообщение от FF (?), 12-Апр-23, 15:25

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

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

77. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от Аноним (77), 12-Апр-23, 17:26

Уже много раз повторялось - прикрутите вы нормальный менеджер памяти типа FastMM, который в FullDebugMode будет жутко тормозить, но зато показывать вообще все возможные косяки. А если будут програть наугад как сейчас, то так и будут вечно страдать от своих use-after-free.

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

133. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 09:19

> Уже много раз повторялось - прикрутите вы нормальный менеджер памяти типа FastMM,
> который в FullDebugMode будет жутко тормозить, но зато показывать вообще все
> возможные косяки. А если будут програть наугад как сейчас, то так
> и будут вечно страдать от своих use-after-free.
Для тех кто этого хотел уже давно есть KASAN. Enjoy your ride (if you can). Но простите, ядро станет именно тем что вы просили.

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

124. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от n00by (ok), 13-Апр-23, 07:35

std::unique_prt<>
Но это породит новые проблемы, из-за использования двух языков. Потому Линус берёг хрупкий внутренний мир бородатых сишников.

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

71. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Иваня (?), 12-Апр-23, 16:58

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

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

74. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (74), 12-Апр-23, 17:04

зачем чекер ? достаточно просто в chatGPT написать - сделай нам хорошо; и всё, делов то на пару минут.

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

75. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от анон (?), 12-Апр-23, 17:06

/fix
Опять дырявая x86.

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

105. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Michael Shigorin (ok), 12-Апр-23, 20:11

Ну кстати, -mptr128 на e2k рубит и use-after-free.

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

22. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (22), 12-Апр-23, 14:51

Мне кажется адепты "это не язык виноват, это программисты" ОБЯЗАНЫ фиксить такие баги и формально доказывать корректность фиксов =)

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

Часть нити удалена модератором

26. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Анонин (?), 12-Апр-23, 15:01

Предлагаю сишникам перестать делать use-after-free!
Это же всего-лишь нужно вызывать free только один раз, они что не в состоянии??

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

31. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +2 +/–

Сообщение от Ivan_83 (ok), 12-Апр-23, 15:12

Вы даже не поняли смысла "use-after-free" а что то предлагаете.
uint8_t *ptr = malloc(10);
ptr[0] = 123;
free(ptr);
ptr[0] = 123; /* Вот тут use-after-free */
В программах бывает так что память освободили а где то остался указатель, например его часто забывают обнулить после освобождения, и потом его кто то юзает.
Если бы было объявлено как: free(void **ptr) и не только освобождало память но и зануляло указатель то use-after-free встречалось бы в разы реже.

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

34. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –2 +/–

Сообщение от Аноним (10), 12-Апр-23, 15:16

Когда не выкупают иронию и самый простой юмор это уже старость.

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

54. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Ivan_83 (ok), 12-Апр-23, 16:00

Не вижу юмора в том, что человек путает double-free и use-after-free.

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

73. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –1 +/–

Сообщение от Анонин (?), 12-Апр-23, 17:04

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

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

119. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (119), 13-Апр-23, 02:05

Как и сишникам в сортах функторов и ко(про)монад. Понаделают своего абстрактного иммутабельного гуано, что потом GC не затыкается

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

143. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 12:38

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

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

134. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 09:21

> Прости чувак, хаскелистам не интересно разбираться в сортах ваших сишных багов.
Как там говорится? "Филин - стратег"? :)

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

78. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (77), 12-Апр-23, 17:28

Привет FreeAndNil из паскаля. Так может C++ не такой уж классный?

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

125. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –2 +/–

Сообщение от n00by (ok), 13-Апр-23, 07:38

Может стоит научиться отличать Си от Си++.

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

141. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (21), 13-Апр-23, 11:12

зачем? с++ это надстройка над си, а не какой-нибудь язык, претендующий на независимость

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

147. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –1 +/–

Сообщение от n00by (ok), 13-Апр-23, 13:26

> зачем?
Что бы не публиковать нижеследующую чепуху:
> с++ это надстройка над си, а не какой-нибудь язык, претендующий на
> независимость

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

160. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (157), 14-Апр-23, 11:17

> с++ это надстройка над си, а не какой-нибудь язык, претендующий на > независимость
Вот ведь блин, а ISO не в курсе такой ерунды и выпускает 2 набора стандартов от 2 разныз рабочих групп.
Более того - compat там далеко не стопроцентный. А как тебе использование "auto" в си и в c++? Думаешь, будет одно и то же? А вот и хрен, совсем разные вещи. В C2x (C23) это может быть изменится. Но он пока не вышел. Или скажем удачи использовать кейворд "register" в плюсах. Так то плюсы "extern C" сделали не просто для красоты.

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

38. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от FF (?), 12-Апр-23, 15:26

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

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

45. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –1 +/–

Сообщение от Аноним (22), 12-Апр-23, 15:35

А почему нужно быть должным кому-то? Иксперды лучше-всех-написаторы могут быть должны себе, ну просто чтобы не быть балаболами. Но, как мы видим, это им не очень интересно. Ведь болтать не мешки ворочать, толк из чип =)

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

56. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +2 +/–

Сообщение от Аноним (56), 12-Апр-23, 16:04

Адепты "язык все исправит" вызвались написать свою ОС без "этих несчастных C проблем" и пока написали только memory leak (что иронично), а теперь почему-то очень уж хотят писать на своём языке в "дырявой системе написанной дедами"

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

69. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Анонимусс (?), 12-Апр-23, 16:54

Как будто без этого "дырявая система написанная дедами" стала менее дырявой?
А писать в ней хотят как раз чтобы сделать ее лучше!

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

90. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (10), 12-Апр-23, 18:11

Как будто с растом что-то изменится.

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

117. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (117), 13-Апр-23, 00:33

Доказать эти сомнения элементарно - приведи пример аналогичного бага в раст коде =)

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

162. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (157), 14-Апр-23, 11:32

> Доказать эти сомнения элементарно - приведи пример аналогичного бага в раст коде =)
Вас забанили на сайте с списком CVE? Там замечательный ассортимент, есть и ошибки управления памятью, и переполнения буфера, и что вы там еще хотели? Да, оказывается так можно было =)

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

139. Скрыто модератором +/–

Сообщение от ivan_erohin (?), 13-Апр-23, 09:34

изменится, и я даже знаю что именно
внимание на скриншоты:
https://habr.com/ru/articles/553000/

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

135. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –1 +/–

Сообщение от Аноним (-), 13-Апр-23, 09:25

> Адепты "язык все исправит" вызвались написать свою ОС без "этих несчастных C
> проблем" и пока написали только memory leak (что иронично), а теперь
> почему-то очень уж хотят писать на своём языке в "дырявой системе
> написанной дедами"
Файрфоксу уже исправили, теперь это чудо природы стало стабильно падать раз в эн по ... выжиранию всей памяти в системе. Довольно странное понимание безопасности. Хотя если программа упала, хакер ее взломать уже не сможет, спору нет. Проблема в том что это как минимум DoS. А в случае с лисом вообще self destruct какой-то.

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

28. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +2 +/–

Сообщение от Анонн (?), 12-Апр-23, 15:04

Ядро 4.14 вышло в ноябре 2017 года.
И никто ничего не заметил. Печально.

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

30. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +4 +/–

Сообщение от Аноним (18), 12-Апр-23, 15:06

> никто ничего не заметил
Ты пишешь под новостью, в которой кто-то что-то все-таки заметил.

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

48. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +2 +/–

Сообщение от Rev (?), 12-Апр-23, 15:48

Всего-то 6 лет понадобилось чтобы заметить. Подумаешь!

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

52. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от Аноним (10), 12-Апр-23, 15:57

А в шинды такой же дыре уже 30 лет.

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

126. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (126), 13-Апр-23, 07:50

это другое

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

83. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от ИмяХ (?), 12-Апр-23, 17:54

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

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

44. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (44), 12-Апр-23, 15:33

На gentoo в новости две ссылки, и обе на несуществующий CVE

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

57. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от Аноним (57), 12-Апр-23, 16:09

> kernel.unprivileged_userns_clone=0
Уже было. Оказыватся, я уже это делал давно, судя по конфигам.

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

59. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +2 +/–

Сообщение от Аноним (10), 12-Апр-23, 16:17

Кто-то всё знал и молчал...пора размотать этот клубок заговоров и лжи.

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

136. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 09:27

> Кто-то всё знал и молчал...пора размотать этот клубок заговоров и лжи.
При том эти заговоры тянутся уже не менее полувека: какие-то п...сы пишут документацию, а другие п...сы ее упорно не читают, даже под угрозой расстрела. Ну вот что с ними делать? На урановые рудники ссылать всех кто RTFM не практикует? Там СТОЛЬКО двуногих не уместится.

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

68. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –3 +/–

Сообщение от Анонимусс (?), 12-Апр-23, 16:53

Если я усну и проснусь через десят лет и меня спросят, что сейчас происходит в си кодах, я отвечу: портят память и рут получают.

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

116. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (116), 12-Апр-23, 23:10

Правильный ответ будет "ничего не происходит", ибо искусственному интеллекту Cи не нужен.

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

81. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от InuYasha (??), 12-Апр-23, 17:39

Кто-нить ещё помнит, зачем отключали QoS во времена Win98? :)))) Вот, теперь и в Линухе пора.

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

92. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от Аноним (10), 12-Апр-23, 18:13

Потому что они хотели чтобы все ушли в NT где всё сделают правильно. Вин98 это веселенький гуй под досом. Почему линукс не может сделать тоже самое чтобы приложеньки всегда запускались? Это не ко мне.

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

108. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +1 +/–

Сообщение от Аноним (108), 12-Апр-23, 21:04

У меня складывается впечатление, что все DE в linux это Win98 над MS-DOS. Я не сравниваю ни DE с Win98 ни GNU/Linux с MS-DOS. Всё не в пользу майкрософт. Но что-то похожее.

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

127. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (126), 13-Апр-23, 07:51

> Но что-то похожее.
в чем похожесть?

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

101. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (67), 12-Апр-23, 19:15

Потому, что там от QoS не было толку.

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

97. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –1 +/–

Сообщение от Егор (??), 12-Апр-23, 18:39

Я не понял они просто выбросили модуль вместо исправления?
От трюкачи ))

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

106. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." –3 +/–

Сообщение от Michael Shigorin (ok), 12-Апр-23, 20:18

> userns
Не понимаю тех, кто просит его включить.

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

109. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (109), 12-Апр-23, 21:43

В Debian 10 этот параметр выключен и тем не менее завели на него статус уязвимо.
В RHEL, Fedora, SUSE, Arch, Gentoo даже нет в базе этого CVE. Допустим они подумали, что он по умолчанию выключен. Но ведь можно и включить.

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

153. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (-), 13-Апр-23, 22:13

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

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

107. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (108), 12-Апр-23, 20:53

12-04-2023 20:51:23
Gentoo, RHEL, SUSE, Fedora, Gentoo, Arch нет этого CVE в багтрекере.
Отреагировали только Debian и Ubuntu.

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

114. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (126), 12-Апр-23, 22:12

Дебиан 9 как всегда торт :)))

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

137. Скрыто модератором +/–

Сообщение от Аноним (-), 13-Апр-23, 09:29

> Дебиан 9 как всегда торт :)))
При том - окаменелый. Для археолога просто клад.

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

145. Скрыто модератором +/–

Сообщение от Аноним (-), 13-Апр-23, 12:42

> Дебиан 9 как всегда торт :)))
Добытый археологами из гробницы фараона.

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

115. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." +/–

Сообщение от Аноним (116), 12-Апр-23, 23:08

>bookworm    6.1.20-1    fixed
>sid    6.1.20-2    fixed
Молодцы.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

2. Скрыто модератором	+/–
Сообщение от Denys (??), 12-Апр-23, 13:57
"обращением к памяти после её освобождения (use-after-free)" классика С/С++, сколько ещё будет таких уязвимостей?
Ответить \| Правка \| Наверх \| Cообщить модератору


	151. Скрыто модератором	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 13-Апр-23, 20:34
	> "обращением к памяти после её освобождения (use-after-free)" > классика С/С++, сколько ещё будет таких уязвимостей? В С++ с использованием RAII такого минимум.
	Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+9 +/–
Сообщение от Аноним (3), 12-Апр-23, 14:01
Что-то этот ваш "user namespace" какой-то перфорированный всё время.
Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+2 +/–
	Сообщение от Аноним (10), 12-Апр-23, 14:12
	Это кого надо спейс. И они его доят.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	130. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+1 +/–
	Сообщение от Аноним (-), 13-Апр-23, 09:07
	Можно подумать это специально. Ядро не делали с учетом таких вещей, изначально система была одна, контейнеров не было, ядро считало CAP_NET_ADMIN безусловным сигналом к действию. А когда всем захотелось контейнеры, сову совместными усилиями натянули на глобус, оказалось что некоторые нюансы все же есть. Ну вот и штопают периодически, когда ядро рута контейнера за рута всей системы воспринимает. А таких мест в ядре в всяких экзотичных краевых случаях наверняка еще есть. В обычной системе могли особо и не париться - если рут сам себе отстрелит пятку, он это и так мог, кому хуже то. А тут вот рут мог быть и не настоящий. Опа.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (18), 12-Апр-23, 14:41
	Слишком вкусная фича, чтобы от нее отказываться.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	72. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+2 +/–
	Сообщение от пох. (?), 12-Апр-23, 17:02
	ну так что ты хочешь от механизма дающего юзеру рута но не вот совсем совсем а так... на пол-шишечки?
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	94. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	–2 +/–
	Сообщение от Аноним (94), 12-Апр-23, 18:23
	Спасибо дидам с их офигенными идеями про привилегированные порты. В семидесятые это может быть и была хорошая идея, но уже в начале века было ясно, что от этого костыля надо избавляться. Почему за 20 лет не избавились — загадка.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	128. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (-), 13-Апр-23, 09:01
	А при чем тут привилегированные порты? В уязвимости ни слова про это, там какие-то экзотичные краевые ситуации, когда раз в год и палка стреляет. А юзерский неймспейс виноват только тем что пытается косить под отдельную систему и там у фэйкового рута могут быть эти права, чтобы свой контейнер настраивать. В данном случае проблема в том что рут контейнера может апгрейднуться до рута всей системы, а вот это уже нехорошо. Однако с практической точки зрения - найти вот именно такой конфиг еще постараться надо, так что реальный масштаб проблемы - мизерный. А часто вы бываете в контейнере, с правами CAP_NET_ADMIN, чтобы оттуда наружу лезть? Ну вот то-то и оно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	148. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	–1 +/–
	Сообщение от Аноним (94), 13-Апр-23, 17:43
	Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN? Ну не для того же, чтобы слушать «привилегированный» порт? Понятно, что не только для этого, и примеров, когда без неймспейса никак тоже хватает, но основная задача таки тривиальна: слушать на портах <1024 без рута. А то, что всякие обскурные механизмы вроде QoS от такого ломаются то не диво. Диды те ещё программисты локалхоста были, они даже представить себе не могли, что в многопользовательской системе пользователи захотят что-то делать полезное, а не только sedеть и gawkать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	150. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (-), 13-Апр-23, 18:54
	> Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN? Ну не > для того же, чтобы слушать «привилегированный» порт? Чтобы "настраивать сеть" на "своем компе" например. То-есть, там свои сетевые интерфейсы, на которые захочится свои айпишники навесить, со стороны контейнера. И все такое. Если хочется чтобы это выглядело как вот именно отдельный комп с линухом. Без этого до вон того дело даже и не дойдет, так то. Видел OpenVZ? Это полная версия той идеи. Они это изначально делали какими-то жуткими патчами, дико лагающими относительно майнлайна по скорости их выпуска. За что и скопытились как виртуалки стали быстрыми и эффективными. Но часть этого в майнлайн внесли, а народ фичу в принципе хочет, так что в целом оно все же есть. > основная задача таки тривиальна: слушать на портах <1024 без рута. Это в линухе делается и без вон тех прав и namespace, экий вы затейник получать эти возможности такой левой пяткой в правое ухо. > А то, что всякие обскурные механизмы вроде QoS от такого ломаются то не диво. И прочие проверки прав и так далее. Но для начала идея в том что контейнер будет типа отдельной машиной, с отдельной сетевой конфигурацией. А чтоб ее настроить пригодится CAP_NET_ADMIN. Он как бы немного виртуальный но, вот, увы, не всегда... > Диды те ещё программисты локалхоста были, они даже представить > себе не могли, что ...что из 1 компа и ОС захотят сделать N типа-независимых с минимальным оверхедом. И да, не могли. Как максимум в соляре зоны были. Ну да, пораньше. Но ядро линукса начали кодить тоже не вчара и тогда такое еще не было в ходу вроде. Это тот случай когда факап на уровне архитектуры, но - увы - при таком размере кодовой базы с ноля рефакторить не вариант, приходится фичу на скотч приделывать. Мир не идеален.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	129. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от 1 (??), 13-Апр-23, 09:04
	Это типа про "звон" ? Причём тут порты ? Тут как раз про любимые контейнеры.
	Ответить \| Правка \| К родителю #94 \| Наверх \| Cообщить модератору


	149. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (94), 13-Апр-23, 17:43
	Зачем тебе контейнеры и почему чрута не хватает? Ага, то-то же.
	Ответить \| Правка \| Наверх \| Cообщить модератору

5. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
Сообщение от marten (ok), 12-Апр-23, 14:08
И опять use-after-free...
Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (10), 12-Апр-23, 14:10
	...ваши предложения?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Rock (?), 12-Апр-23, 14:47
	> ...ваши предложения? Очевидно же -- free должна портить память. Либо скорость, либо безопасность.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (18), 12-Апр-23, 16:40
	> Либо скорость, либо безопасность насколько это: free(ptr); быстрее, чем это: free(ptr); ptr = NULL; ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+2 +/–
	Сообщение от Аноним (67), 12-Апр-23, 16:52
	Незаметно. Удивительно, что дизайнеры C/POSIX API не сделали так, чтобы этот NULL возвращала функция free() после успешного освобождения. ptr = free(ptr);
	Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+1 +/–
	Сообщение от Аноним (18), 12-Апр-23, 17:13
	ты можешь написать макрос, который будет вызывать free() и обнулять переменную. Вызывать так: clear(ptr). Оставлю тебе на дом, каким должен быть #define clear.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	79. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+1 +/–
	Сообщение от InuYasha (??), 12-Апр-23, 17:37
	Вот, только каждый программист напишет своих подобных костылей с разными названиями и поведением - и сиди, сходи с ума, изучая всё это. Хотя, даже позикс иногда объявляется устаревшим - что уж там... PS: только не макрос лучше, а инлайн, наверное.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	84. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (18), 12-Апр-23, 17:54
	это лучше, чем заставлять free возвращать что-то там, хотя на самом деле ему возвращать особо нечего. Незачем городить дополнительные машинные коды ради какого-то призрачного удобства при разработке. Если нужно удобство, пили макросы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	–1 +/–
	Сообщение от InuYasha (??), 12-Апр-23, 18:55
	По мне - так любая функция должна возвращать если не HRESULT, то хоть bool success. Ну, не glVertex3f, конечно, где прям за каждый такт трясёшься. (да, я знаю! это просто пример!)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	99. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от InuYasha (??), 12-Апр-23, 18:56
	И, да, я знаю про try - throw - catch, но оно дико стрёмное.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	157. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (157), 14-Апр-23, 09:14
	> И, да, я знаю про try - throw - catch, но оно > дико стрёмное. В сях вообще нет этих понятий. Да и вон то далеко не везде катит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	123. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от n00by (ok), 13-Апр-23, 07:27
	> Удивительно, что дизайнеры C/POSIX API не сделали так, чтобы этот NULL возвращала > функция free() после успешного освобождения. > ptr = free(ptr); А в случае неуспешного освобождения что будет возвращать free()?
	Ответить \| Правка \| К родителю #67 \| Наверх \| Cообщить модератору


	131. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (-), 13-Апр-23, 09:14
	Неуспешное освобождение памяти - это что?! Как на чисто логическом уровне это могло бы выгдядеть вообще? Потому что в free() такой вариант не присутствует. См man 3 free. В самых идиотских ситуациях (попытки освободить то что не выделяли или уже освободили) - в спеках на функцию сказано "undefined behavior". В идеале такие вещи следовало бы ловить но видимо трекинг аллокаций и проверка этого при free() достаточно дорого по скорости и оверхеду обходится.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	140. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от n00by (ok), 13-Апр-23, 10:10
	> Неуспешное освобождение памяти - это что?! Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал. > Как на чисто логическом уровне это > могло бы выгдядеть вообще? Потому что в free() такой вариант не > присутствует. См man 3 free. ISO/IEC 9899:2017 7.22.3.3 The free function 2 ... if the argument does not match a pointer earlier returned by a memory management function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined. > В самых идиотских ситуациях (попытки освободить то что не выделяли или уже > освободили) - в спеках на функцию сказано "undefined behavior". В идеале > такие вещи следовало бы ловить но видимо трекинг аллокаций и проверка > этого при free() достаточно дорого по скорости и оверхеду обходится. И что возвращать в этом случае? Если NULL, тогда можно самому занулять указатель, как и предалали. Если не NULL, тогда рац.предожение теряет смысл. Потому и не вижу ничего удивительно в текущей реализации.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	142. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (-), 13-Апр-23, 12:35
	> Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал. В вон том определении реализации функции просто нет места "call fails" - либо всегда success, либо UB. Если что, UB != call fails. > deallocated by a call to free or realloc, the behavior is undefined. Ну и как видите в этом (да, достаточно дурацком) определении не предусмотренно именно "fails". Вместо этого "хз что будет, ваша проблема". И вообще-то это пример того как апи делать не надо. Но в сях у комитета есть мерзкая привычка спихивать свои проблемы на других, чтобы не прописывать конкретику behavir. На мой вкус тут вопрос скорее к стандарту и апи самому по себе. Уж как минимум обязать free вешать null на указатель и чекать при входе в него что дали null и репортить жесткий usage error, вплоть до краха программы, было бы весьма логично (и не так уж дорого по ресурсам). Ядерщики кстати могли бы себе нечто такое и сделать - они стандартами си и тем более фичами libc не зажаты так то и у них много забавного кастома есть. > И что возвращать в этом случае? По уму это апи надо переделать, но мы повесимся из за слома совместимости. > Если NULL, тогда можно самому занулять указатель, как и предалали. > Если не NULL, тогда рац.предожение теряет смысл. Потому и не вижу ничего > удивительно в текущей реализации. Мне вообще вот это апи не особо нравится. Я бы вообще запретил комитетчикам использовать слово "undefined behavior". Ибо нефиг.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	146. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от n00by (ok), 13-Апр-23, 13:17
	>> Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал. > В вон том определении реализации функции просто нет места "call fails" - > либо всегда success, либо UB. Если что, UB != call fails. "call fails" входит в множество UB. Если что, я знаю, что ты любишь высказывать мнение по вопросам, в коих понимаешь мало. Я уже просил тебя не тратить моё время и не мешать мне переписываться с другими Анонимами.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	152. "Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..."	+/–
	Сообщение от Аноним (-), 13-Апр-23, 22:07
	> "call fails" входит в множество UB. Call fails - как раз обычно well defined behavior, как именно проверить (не)успех операции при этом явно прописывается в документации. Как в манах линукса, on success... returns X, on failure... returns Y and sets errno to 123. И так далее. Для free() идентификация fail его вызова в стандарте не прописана, такого понятия для этой функции в стандарте просто нет. Если не указана конкретика как проверить call failed, мы не можем узнать что он failed, и это понятие не имеет смысла. А если указано - тогда это уже "defined behavior", никак не UB. И в этом аспекте free() не имеет понятия "call failed" в определении интерфейса. Только некорректное использование, но это другое. > Если что, я знаю, что ты любишь высказывать мнение по вопросам, в > коих понимаешь мало. > Я уже просил тебя не тратить моё время и не мешать мне > переписываться с другими Анонимами. Наверное вы меня с кем-то перепутали, не припоминаю такое. Но уровень снобизма в паре с некомпетентностью заценил, так что определенный пойнт в ваших словах все же есть.
	Ответить \| Правка \| Наверх \| Cообщить модератору