В ядре Linux выявлены две уязвимости (CVE-2023-1281, CVE-2023-1829), позволяющие локальному пользователю поднять свои привилегии в системе. Для проведения атаки требуются полномочия на создание и изменение классификаторов трафика, доступные при наличии прав CAP_NET_ADMIN, которые можно получить при возможности создания пространств имён идентификаторов пользователя (user namespace). Проблемы проявляются начиная с ядра 4.14 и устранены в ветке 6.2...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58955
"обращением к памяти после её освобождения (use-after-free)"классика С/С++, сколько ещё будет таких уязвимостей?
> "обращением к памяти после её освобождения (use-after-free)"
> классика С/С++, сколько ещё будет таких уязвимостей?В С++ с использованием RAII такого минимум.
Что-то этот ваш "user namespace" какой-то перфорированный всё время.
Это кого надо спейс. И они его доят.
Можно подумать это специально. Ядро не делали с учетом таких вещей, изначально система была одна, контейнеров не было, ядро считало CAP_NET_ADMIN безусловным сигналом к действию. А когда всем захотелось контейнеры, сову совместными усилиями натянули на глобус, оказалось что некоторые нюансы все же есть. Ну вот и штопают периодически, когда ядро рута контейнера за рута всей системы воспринимает. А таких мест в ядре в всяких экзотичных краевых случаях наверняка еще есть.В обычной системе могли особо и не париться - если рут сам себе отстрелит пятку, он это и так мог, кому хуже то. А тут вот рут мог быть и не настоящий. Опа.
Слишком вкусная фича, чтобы от нее отказываться.
ну так что ты хочешь от механизма дающего юзеру рута но не вот совсем совсем а так... на пол-шишечки?
Спасибо дидам с их офигенными идеями про привилегированные порты. В семидесятые это может быть и была хорошая идея, но уже в начале века было ясно, что от этого костыля надо избавляться. Почему за 20 лет не избавились — загадка.
А при чем тут привилегированные порты? В уязвимости ни слова про это, там какие-то экзотичные краевые ситуации, когда раз в год и палка стреляет.А юзерский неймспейс виноват только тем что пытается косить под отдельную систему и там у фэйкового рута могут быть эти права, чтобы свой контейнер настраивать. В данном случае проблема в том что рут контейнера может апгрейднуться до рута всей системы, а вот это уже нехорошо.
Однако с практической точки зрения - найти вот именно такой конфиг еще постараться надо, так что реальный масштаб проблемы - мизерный. А часто вы бываете в контейнере, с правами CAP_NET_ADMIN, чтобы оттуда наружу лезть? Ну вот то-то и оно.
Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN? Ну не для того же, чтобы слушать «привилегированный» порт? Понятно, что не только для этого, и примеров, когда без неймспейса никак тоже хватает, но основная задача таки тривиальна: слушать на портах <1024 без рута. А то, что всякие обскурные механизмы вроде QoS от такого ломаются то не диво. Диды те ещё программисты локалхоста были, они даже представить себе не могли, что в многопользовательской системе пользователи захотят что-то делать полезное, а не только sedеть и gawkать.
> Зачем, казалось бы, юзеру отдельный неймспейс с рутом и CAP_NET_ADMIN? Ну не
> для того же, чтобы слушать «привилегированный» порт?Чтобы "настраивать сеть" на "своем компе" например. То-есть, там свои сетевые интерфейсы, на которые захочится свои айпишники навесить, со стороны контейнера. И все такое. Если хочется чтобы это выглядело как вот именно отдельный комп с линухом.
Без этого до вон того дело даже и не дойдет, так то. Видел OpenVZ? Это полная версия той идеи. Они это изначально делали какими-то жуткими патчами, дико лагающими относительно майнлайна по скорости их выпуска. За что и скопытились как виртуалки стали быстрыми и эффективными. Но часть этого в майнлайн внесли, а народ фичу в принципе хочет, так что в целом оно все же есть.
> основная задача таки тривиальна: слушать на портах <1024 без рута.
Это в линухе делается и без вон тех прав и namespace, экий вы затейник получать эти возможности такой левой пяткой в правое ухо.
> А то, что всякие обскурные механизмы вроде QoS от такого ломаются то не диво.
И прочие проверки прав и так далее. Но для начала идея в том что контейнер будет типа отдельной машиной, с отдельной сетевой конфигурацией. А чтоб ее настроить пригодится CAP_NET_ADMIN. Он как бы немного виртуальный но, вот, увы, не всегда...
> Диды те ещё программисты локалхоста были, они даже представить
> себе не могли, что...что из 1 компа и ОС захотят сделать N типа-независимых с минимальным оверхедом. И да, не могли. Как максимум в соляре зоны были. Ну да, пораньше. Но ядро линукса начали кодить тоже не вчара и тогда такое еще не было в ходу вроде.
Это тот случай когда факап на уровне архитектуры, но - увы - при таком размере кодовой базы с ноля рефакторить не вариант, приходится фичу на скотч приделывать. Мир не идеален.
Это типа про "звон" ? Причём тут порты ? Тут как раз про любимые контейнеры.
Зачем тебе контейнеры и почему чрута не хватает? Ага, то-то же.
И опять use-after-free...
...ваши предложения?
> ...ваши предложения?Очевидно же -- free должна портить память. Либо скорость, либо безопасность.
> Либо скорость, либо безопасностьнасколько это:
free(ptr);
быстрее, чем это:
free(ptr);
ptr = NULL;?
Незаметно.
Удивительно, что дизайнеры C/POSIX API не сделали так, чтобы этот NULL возвращала функция free() после успешного освобождения.
ptr = free(ptr);
ты можешь написать макрос, который будет вызывать free() и обнулять переменную. Вызывать так: clear(ptr). Оставлю тебе на дом, каким должен быть #define clear.
Вот, только каждый программист напишет своих подобных костылей с разными названиями и поведением - и сиди, сходи с ума, изучая всё это. Хотя, даже позикс иногда объявляется устаревшим - что уж там...
PS: только не макрос лучше, а инлайн, наверное.
это лучше, чем заставлять free возвращать что-то там, хотя на самом деле ему возвращать особо нечего. Незачем городить дополнительные машинные коды ради какого-то призрачного удобства при разработке. Если нужно удобство, пили макросы.
По мне - так любая функция должна возвращать если не HRESULT, то хоть bool success. Ну, не glVertex3f, конечно, где прям за каждый такт трясёшься. (да, я знаю! это просто пример!)
И, да, я знаю про try - throw - catch, но оно дико стрёмное.
> И, да, я знаю про try - throw - catch, но оно > дико стрёмное.В сях вообще нет этих понятий. Да и вон то далеко не везде катит.
> Удивительно, что дизайнеры C/POSIX API не сделали так, чтобы этот NULL возвращала
> функция free() после успешного освобождения.
> ptr = free(ptr);А в случае неуспешного освобождения что будет возвращать free()?
Неуспешное освобождение памяти - это что?! Как на чисто логическом уровне это могло бы выгдядеть вообще? Потому что в free() такой вариант не присутствует. См man 3 free.В самых идиотских ситуациях (попытки освободить то что не выделяли или уже освободили) - в спеках на функцию сказано "undefined behavior". В идеале такие вещи следовало бы ловить но видимо трекинг аллокаций и проверка этого при free() достаточно дорого по скорости и оверхеду обходится.
> Неуспешное освобождение памяти - это что?!Это ситуация, обратная успешному освобождению. См №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, тогда рац.предожение теряет смысл. Потому и не вижу ничего удивительно в текущей реализации.
> Это ситуация, обратная успешному освобождению. См №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". Ибо нефиг.
>> Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал.
> В вон том определении реализации функции просто нет места "call fails" -
> либо всегда success, либо UB. Если что, UB != call fails."call fails" входит в множество UB.
Если что, я знаю, что ты любишь высказывать мнение по вопросам, в коих понимаешь мало.
Я уже просил тебя не тратить моё время и не мешать мне переписываться с другими Анонимами.
> "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" в определении интерфейса. Только некорректное использование, но это другое.
> Если что, я знаю, что ты любишь высказывать мнение по вопросам, в
> коих понимаешь мало.
> Я уже просил тебя не тратить моё время и не мешать мне
> переписываться с другими Анонимами.Наверное вы меня с кем-то перепутали, не припоминаю такое. Но уровень снобизма в паре с некомпетентностью заценил, так что определенный пойнт в ваших словах все же есть.
>> "call fails" входит в множество UB.
> Call fails - как раз обычно well defined behaviorЯ уже понял, что операции над множествами - не твоё.
Не требуется дальше убеждать меня в этом.
А у вас проблемы с логическими операциями. Для меня выглядит так как будто это ЛИБО undefined behavior, ЛИБО, если понятие call fails определено, тогда рассказано как определить fail, и тогда это уже defined behavior. Вы, кажется, этого не поняли.Defined behavior отличается от undefined как раз тем что конкретно расписано что и как происходит. Если это расписано для call fails - окей, это defined behavior, мы можем определить это в caller'е. А в вон том случае "call fails" просто не определен как сущность. Этого понятия не существует для этой функции, как минимум в стандарте.
С точки зрения реализации видимо идея была такая что на этот момент все ресурсы которые надо было выделить уже были успешно выделены, новых не надо и как может обломиться чистая математика и маркировка регионов - загадка. Если случилось что-то вообще совсем странное, типа read или write error в каком-нибудь там свопфайле, это уже глубокая и невосстановимая системная ошибка и там разве что SIGSEGV какой процессу прислать, или что там по мнению системы уместно, когда выполнение процесса совсем нельзя возобновить в нужном виде.
> А у вас проблемы с логическими операциями.Это не имеет отношения к UB и твоему непониманию, что такое UB.
По-моему самое непосредственное отношение. Либо поведение определено (и подлежит документированию), либо нет. Это бинарная величина. Для free() не определено понятие фэйла при легитимном использовани, его просто нет. Если понятия нет, оно не может входить в какое либо множество.При нормальном использовании в пределах спеков видимо считается что он всегда успешен, там нет места для fails в результатах вызова, стало быть это понятие просто не существует в этих абстракциях. Это скорее из категории "should never happen".
И на самом деле это как раз ключевая грабля стандартов на си и их стдлиб, там очень много чего недоопределено, определено неоднозначно или допускает UB. И за это временами тех господ из ISO хочется немножечко придушить.
3.4.31 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).и разрешено документировать поведение, что как раз и оправдано в ядре.
> Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".Для функции "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 и тому подобных штук.
>> Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".
> Для функции "free" в стандарте ничего не сказано про то что эта
> операция вообще может обломаться.Всё там сказано, читайте цитаты в моих сообщениях, начиная с №140. Или учитесь их понимать, если уже читали.
>> Либо скорость, либо безопасность
> насколько это:
> free(ptr);
> быстрее, чем это:
> free(ptr);
> ptr = NULL;
> ?Ну, вот, как порча указателя на память связана с порчей памяти? Речь шла о том, что free могла бы обнулять память ради безопасности. Очевидно, что повлиять на указатели на эту память, сохраненные где-то снаружи, она чисто технически никак не может.
Я вообще не понимаю людей на этом форуме...
Предлагаю сишникам наконец-то перестать портить память!
собирать мусор 30 минут, как в джаваскрипте
В JS (V8,JavaScriptCore) довольно быстрый сборщик мусора - в отличие от сишного дидовского кода, где memory-leak-мусор по всей системе и убирать его не спешат.
джаваскрипт легендарен своей текущей jvm, учи матчасть
> В JS (V8,JavaScriptCore) довольно быстрый сборщик мусора -Угу, именно поэтому при потугах что-то активно делать все тормозит а браузер жрет гигазы оперативы. Достаточно посмотреть как работают например игровые движки, это достаточно здоровые штуки чтобы хотеть именно постоянную аллокацию-деаллокацию, т.к. держать в памяти всообще все ассеты более-менее приличной гамезы малореально.
да они не понимают, что такие ситуации можно отследить только контролем за каждой ссылкой, а значит затормаживанием операций, это же в многозадачной среде никакой канпилятор не отследит, т.к. они асинхронно работают, а за всеми проверками не уследишь.
Уже много раз повторялось - прикрутите вы нормальный менеджер памяти типа FastMM, который в FullDebugMode будет жутко тормозить, но зато показывать вообще все возможные косяки. А если будут програть наугад как сейчас, то так и будут вечно страдать от своих use-after-free.
> Уже много раз повторялось - прикрутите вы нормальный менеджер памяти типа FastMM,
> который в FullDebugMode будет жутко тормозить, но зато показывать вообще все
> возможные косяки. А если будут програть наугад как сейчас, то так
> и будут вечно страдать от своих use-after-free.Для тех кто этого хотел уже давно есть KASAN. Enjoy your ride (if you can). Но простите, ядро станет именно тем что вы просили.
std::unique_prt<>Но это породит новые проблемы, из-за использования двух языков. Потому Линус берёг хрупкий внутренний мир бородатых сишников.
Не ной, сделай чекер, который будет находить такое и исправлять.
зачем чекер ? достаточно просто в chatGPT написать - сделай нам хорошо; и всё, делов то на пару минут.
/fix
Опять дырявая x86.
Ну кстати, -mptr128 на e2k рубит и use-after-free.
Мне кажется адепты "это не язык виноват, это программисты" ОБЯЗАНЫ фиксить такие баги и формально доказывать корректность фиксов =)
Предлагаю сишникам перестать делать use-after-free!
Это же всего-лишь нужно вызывать free только один раз, они что не в состоянии??
Вы даже не поняли смысла "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 встречалось бы в разы реже.
Когда не выкупают иронию и самый простой юмор это уже старость.
Не вижу юмора в том, что человек путает double-free и use-after-free.
Прости чувак, хаскелистам не интересно разбираться в сортах ваших сишных багов.
Но спасибо, буду знать. Но тогда предлагаю запретить и то, и другое!
Как и сишникам в сортах функторов и ко(про)монад. Понаделают своего абстрактного иммутабельного гуано, что потом GC не затыкается
Более того - код на хаскеле обычно в результате никто кроме его автора не понимает и майнтенансу он не подлежит в принципе. Одна из причин по которым оно не взлетает уже сколько там лет. Ну вот не годится это для написания софта которым потом еще и пользоваться вдолгую будут. Извините но софт пишут не для того чтобы потом неделю раскуривать полет мысли абстракциониста курнувшего что-то резко нестандартное.
> Прости чувак, хаскелистам не интересно разбираться в сортах ваших сишных багов.Как там говорится? "Филин - стратег"? :)
Привет FreeAndNil из паскаля. Так может C++ не такой уж классный?
Может стоит научиться отличать Си от Си++.
зачем? с++ это надстройка над си, а не какой-нибудь язык, претендующий на независимость
> зачем?Что бы не публиковать нижеследующую чепуху:
> с++ это надстройка над си, а не какой-нибудь язык, претендующий на
> независимость
> с++ это надстройка над си, а не какой-нибудь язык, претендующий на > независимостьВот ведь блин, а ISO не в курсе такой ерунды и выпускает 2 набора стандартов от 2 разныз рабочих групп.
Более того - compat там далеко не стопроцентный. А как тебе использование "auto" в си и в c++? Думаешь, будет одно и то же? А вот и хрен, совсем разные вещи. В C2x (C23) это может быть изменится. Но он пока не вышел. Или скажем удачи использовать кейворд "register" в плюсах. Так то плюсы "extern C" сделали не просто для красоты.
мне кажется, адепты, которым кто-то чего-то должен, просто не могут достать из лужи выпавшую соску сидя в коляске
А почему нужно быть должным кому-то? Иксперды лучше-всех-написаторы могут быть должны себе, ну просто чтобы не быть балаболами. Но, как мы видим, это им не очень интересно. Ведь болтать не мешки ворочать, толк из чип =)
Адепты "язык все исправит" вызвались написать свою ОС без "этих несчастных C проблем" и пока написали только memory leak (что иронично), а теперь почему-то очень уж хотят писать на своём языке в "дырявой системе написанной дедами"
Как будто без этого "дырявая система написанная дедами" стала менее дырявой?
А писать в ней хотят как раз чтобы сделать ее лучше!
Как будто с растом что-то изменится.
Доказать эти сомнения элементарно - приведи пример аналогичного бага в раст коде =)
> Доказать эти сомнения элементарно - приведи пример аналогичного бага в раст коде =)Вас забанили на сайте с списком CVE? Там замечательный ассортимент, есть и ошибки управления памятью, и переполнения буфера, и что вы там еще хотели? Да, оказывается так можно было =)
изменится, и я даже знаю что именно
внимание на скриншоты:
https://habr.com/ru/articles/553000/
> Адепты "язык все исправит" вызвались написать свою ОС без "этих несчастных C
> проблем" и пока написали только memory leak (что иронично), а теперь
> почему-то очень уж хотят писать на своём языке в "дырявой системе
> написанной дедами"Файрфоксу уже исправили, теперь это чудо природы стало стабильно падать раз в эн по ... выжиранию всей памяти в системе. Довольно странное понимание безопасности. Хотя если программа упала, хакер ее взломать уже не сможет, спору нет. Проблема в том что это как минимум DoS. А в случае с лисом вообще self destruct какой-то.
Ядро 4.14 вышло в ноябре 2017 года.
И никто ничего не заметил. Печально.
> никто ничего не заметилТы пишешь под новостью, в которой кто-то что-то все-таки заметил.
Всего-то 6 лет понадобилось чтобы заметить. Подумаешь!
А в шинды такой же дыре уже 30 лет.
это другое
Все видели, кому это надо было. Писали руткиты и продавали их, и/или получали заказы на взломы.
На gentoo в новости две ссылки, и обе на несуществующий CVE
> kernel.unprivileged_userns_clone=0Уже было. Оказыватся, я уже это делал давно, судя по конфигам.
Кто-то всё знал и молчал...пора размотать этот клубок заговоров и лжи.
> Кто-то всё знал и молчал...пора размотать этот клубок заговоров и лжи.При том эти заговоры тянутся уже не менее полувека: какие-то п...сы пишут документацию, а другие п...сы ее упорно не читают, даже под угрозой расстрела. Ну вот что с ними делать? На урановые рудники ссылать всех кто RTFM не практикует? Там СТОЛЬКО двуногих не уместится.
Если я усну и проснусь через десят лет и меня спросят, что сейчас происходит в си кодах, я отвечу: портят память и рут получают.
Правильный ответ будет "ничего не происходит", ибо искусственному интеллекту Cи не нужен.
Кто-нить ещё помнит, зачем отключали QoS во времена Win98? :)))) Вот, теперь и в Линухе пора.
Потому что они хотели чтобы все ушли в NT где всё сделают правильно. Вин98 это веселенький гуй под досом. Почему линукс не может сделать тоже самое чтобы приложеньки всегда запускались? Это не ко мне.
У меня складывается впечатление, что все DE в linux это Win98 над MS-DOS. Я не сравниваю ни DE с Win98 ни GNU/Linux с MS-DOS. Всё не в пользу майкрософт. Но что-то похожее.
> Но что-то похожее.в чем похожесть?
Потому, что там от QoS не было толку.
Я не понял они просто выбросили модуль вместо исправления?
От трюкачи ))
> usernsНе понимаю тех, кто просит его включить.
В Debian 10 этот параметр выключен и тем не менее завели на него статус уязвимо.
В RHEL, Fedora, SUSE, Arch, Gentoo даже нет в базе этого CVE. Допустим они подумали, что он по умолчанию выключен. Но ведь можно и включить.
> В Debian 10 этот параметр выключен и тем не менее завели на
> него статус уязвимо.Видимо чтобы трекать поставки фикшеных ядер. Ну как, поставлять ядро с известной дырой, даже и не активной в дефолтном конфиге, все же моветон.
12-04-2023 20:51:23
Gentoo, RHEL, SUSE, Fedora, Gentoo, Arch нет этого CVE в багтрекере.
Отреагировали только Debian и Ubuntu.
Дебиан 9 как всегда торт :)))
> Дебиан 9 как всегда торт :)))При том - окаменелый. Для археолога просто клад.
> Дебиан 9 как всегда торт :)))Добытый археологами из гробницы фараона.
>bookworm 6.1.20-1 fixed
>sid 6.1.20-2 fixedМолодцы.