LINUX.ORG.RU

Новые серьезные уязвимости в ядре Linux и systemd

 


0

1

CVE-2021-33909 – проблема связана с неправильной обработкой длины имени файла. У пользователя есть возможность выполнить код с root-правами.

https://access.redhat.com/security/cve/cve-2021-33909

CVE-2021-33910 – проблемы со стеком, приводящие к падению systemd.

https://access.redhat.com/security/cve/CVE-2021-33910



Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 3)

Ответ на: комментарий от SZT

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

https://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource делает именно это. Если не дописывать std::pmr::null_memory_resource то он сначала будет использовать фиксированный буфер, потом когда закончится он выделит с помощью new новый буфер и будет использовать его…

fsb4000 ★★★★★
()
Ответ на: комментарий от Xintrea

И уже в плюсах в стандарте с начала века закреплено: пользуйте and/or/not и не ошибётесть

Что ты несёшь? В С тоже есть and/or/not.

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

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

Или с std::string с его small object optimization. Нет-нет, а потом хлоп - и строка.

anonymous
()
Ответ на: комментарий от anonymous

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

С такой формулировкой согласен.

Siborgium ★★★★★
()
Ответ на: комментарий от SZT

«Как будто С++ запрещает использовать alloca/strdupa. » ты ответил «В C++ есть более удобные способы выбирать дёргать память со стека или с хипа в зависимости от запрашиваемого размера.»

Насчёт «более удобные» я, конечно, облажался. В C++ они просто есть. А в C таких способов нету.

utf8nowhere ★★★
()
Ответ на: комментарий от Xintrea

ублюдочный синтаксис языка

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

уже в плюсах в стандарте с начала века закреплено: пользуйте and/or/not

А, вы там вообще на веществах…

anonymous
()
Ответ на: комментарий от utf8nowhere

Да, но есть же.

iso646.h тоненький заголовочный файл, его включение не замедлит компиляцию, а больше причин не использовать и нет, если хочется and вместо &&

fsb4000 ★★★★★
()
Ответ на: комментарий от utf8nowhere

В C++ они просто есть. А в C таких способов нету.

bool malloc_used = false;
void *ptr;
if(need_huge_allocation)
{
  malloc_used = true;
  ptr = malloc(sz);
  if(ptr == NULL)
  {
    //...
  }
}
else
{
  ptr = alloca(sz);
}
//...
if(malloc_used == true)
{
  free(ptr);
}
SZT ★★★★★
()
Ответ на: комментарий от utf8nowhere

А какие способы есть в крестах, которых нет в Си? Я могу и в C сделать массив из char известного размера и из него использовать память.

А еще в Си есть VLA, так что можно сделать что-то типа такого

bool malloc_used = false;
void *ptr;
size_t vla_sz = sz;
if(need_huge_allocation)
{
  vla_sz = 0;
}
char vla[vla_sz];
if(need_huge_allocation)
{
  malloc_used = true;
  ptr = malloc(sz);
  if(ptr == NULL)
  {
    //...
  }
}
else
{
  ptr = vla;
}
//...
if(malloc_used == true)
{
  free(ptr);
}
Что насчет крестов?

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 2)
Ответ на: комментарий от SZT

А какие способы есть в крестах, которых нет в Си? Я могу и в C сделать массив из char известного размера и из него использовать память.

Не можешь, strict aliasing не позволяет.

utf8nowhere ★★★
()
Ответ на: комментарий от SZT

Ты путаешь «к объекту любого типа можно получать доступ через lvalue типа char» с «к объекту типа char можно получать доступ через lvalue любого типа». Второго разрешения не существует, что не позволяет использовать массивы char для хранения других объектов.

utf8nowhere ★★★
()
Последнее исправление: utf8nowhere (всего исправлений: 1)
Ответ на: комментарий от utf8nowhere

к объекту типа char можно получать доступ через lvalue любого типа

Предполагается, что он инициализирует эту память(наверное, как иначе).

anonymous
()
Ответ на: комментарий от utf8nowhere

Значит стандарт здесь неверен. А какая-нибудь реализация данное свойство проявляет?

anonymous
()
Ответ на: комментарий от utf8nowhere

И относительно C++ хотелось бы по тому же вопросу мнение услышать. Это ввиду наличия aligned_storage.

anonymous
()
Ответ на: комментарий от utf8nowhere

Второго разрешения не существует, что не позволяет использовать массивы char для хранения других объектов.

А из чего конкретно следует, что это явно запрещено? Цитату из стандарта можно?

В любом случае, сам массив в стеке можно сделать нужного типа, а еще всегда есть вариант воспользоваться memcpy чтобы записывать и читать какие угодно объекты из char массива. Или это можно делать через union.

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 2)
Ответ на: комментарий от anonymous

В C++ вообще нет понятия declared/effective type. Ну и получать доступ к объекту типа char через что угодно тоже нельзя.

До появления понятия provides storage aligned_storage был «волшебным» типом, который не подчинялся «обычным» правилам, т.е. не подыхал оттого, что поверх него (его мембера) создавали объект другого типа.

utf8nowhere ★★★
()
Последнее исправление: utf8nowhere (всего исправлений: 1)
Ответ на: комментарий от SZT

А из чего конкретно следует, что это явно запрещено? Цитату из стандарта можно?

http://port70.net/~nsz/c/c11/n1570.html#6.5p7

В любом случае, сам массив в стеке можно сделать нужного типа

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

utf8nowhere ★★★
()
Ответ на: комментарий от utf8nowhere

Ясно, уже исправили значит(хоть и без char, но это не важно).

anonymous
()
Ответ на: комментарий от utf8nowhere

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

Ну так union или memcpy эту проблему отлично решают. Так что в Си это можно. Да и стрикт-алиазинг можно отрубить флагами или через __attribute__((__may_alias__))

SZT ★★★★★
()
Ответ на: комментарий от utf8nowhere

Мне кажется, программисты на C не очень боятся UB, пока «у меня все работает».

А потом появляются советы типа «не апгрейдитесь с gcc 4.8 - там UB появляется по-другому и ваши программы будут падать» (это было про проверки типа if (this == NULL)).

Или же «не используйте уровень оптимизации выше -O2». Были интересные примеры с инициализацией глобальных переменных, которые оптимизировались к system("rm -rf /", чего, понятно, быть не должно.

Или пример из статьи с launder - когда код сворачивается до return 4.

anonymous
()
Ответ на: комментарий от anonymous

Мне кажется, программисты на C не очень боятся UB, пока «у меня все работает».

А оно всегда работает, если UB из разряда «забыли что-то уточнить в стандарте» либо «написали неоднозначно». Тот же launder посмотри зачем появился(это не новая возможность, это исправление ошибок в стандарте - хотя, именно здесь не везде работало, да).

Так же и с char[]. Без этого у тебя просто нет возможности получить нединамическую память по объекты неизвестных типов. Те же аллокаторы, например. Т. е. не обёртка над маллок, а что-то вида

// global ns
char mem[...];
void* memalloc(size_t) { ... /* берём память с mem */ }
void memfree(void*) { ... /* аналогично */ }

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

anonymous
()
Ответ на: комментарий от anonymous

Вот. Это все ub из разряда type punning. Для меня было неожиданностью (и все равно это очень низкоуровнево), что кроме memory lifetime, есть ещё object lifetime.

С одной стороны: «какая нафиг разница? Это все равно байты». Но вот для компилятора (а скорее, для оптимизатора) - есть. Тот же клаузюль, что «присваивание мемберу union другого типа прекращает object lifetime предыдущего».

С атомиками тоже интересно. На x86 смотришь на дизассемблер, а там простой mov mem -> reg…

anonymous
()
Ответ на: комментарий от anonymous

union с перечислением всех возможных вариантов разве что.

Вообще-то можно выделяемые поверх массива из char типы делать юнионами, в который входит нужный тип и массив из char. Необязательно сам массив на стеке делать юнионом с всем подряд

Да и вообще, какая-то надуманная проблема. Хоть alloca() формально и не входит в стандарт Си, попробуйте найти актуальный компилятор Си, в котором этого alloca() реально б не было

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 2)
Ответ на: комментарий от SZT

Да, такой вариант с union, кажется, будет работать.

Да и вообще, какая-то надуманная проблема.

Ну да, я об этом в том числе говорю. Тот же char[] сейчас и без union работает.

anonymous
()
Ответ на: комментарий от anonymous

Мне кажется, программисты на C не очень боятся UB, пока «у меня все работает».

А чё бедолагам, которых собственный комитет стандартизации кинул, выдав пачку невменяемой макулатуры в качестве стандарта, ещё делать?

utf8nowhere ★★★
()
Ответ на: комментарий от anonymous

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

Что ж ты такой понимающий ссышься под своим именем на форум зайти? Показал бы свое понимание, тебе бы понапихали по самые помидоры, и все бы знали что стоят твои утверждения.

Xintrea ★★★★★
()
Ответ на: комментарий от fsb4000

В С тоже есть and/or/not.

В каком стандарте? Смотрю последний ISO/IEC 9899:202x (E), раздел «Logical AND operator» и «Logical OR operator», никакого упоминания про and/or/not нет.

Xintrea ★★★★★
()
Ответ на: комментарий от Xintrea

Кстати, интересное отличие С++ от С в этом плане: в С++ убрали трирафы, а and, not и прочее - ключевые слова, а не макросы.

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

anonymous
()
Ответ на: комментарий от anc

И генту, и еще куча дистров без этой дряни.

Dog ★★★
()
Ответ на: комментарий от cocucka

Системд. Блин, да, я сам уже на фряху поглядываю, но есть пара моментов, которые мешают перейти. Линуксы катятся куда-то не туда.

Dog ★★★
()
Последнее исправление: Dog (всего исправлений: 1)
Ответ на: комментарий от Dog

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

Юзерспейс GNU нужен? Или лицензия GPL? Есть еще активно пилящаяся HyperbolaBSD (которая пока еще Hyperbola linux) — полностью свободная (одобрена FSF) Arch based ОС с ядром OpenBSD (пакетный менеджер Pacman, поддержка AUR, пакеты так же разбиваются, без systemd, хоть и все еще с ядром линукс).

Kinlipan
()
Последнее исправление: Kinlipan (всего исправлений: 3)
Ответ на: комментарий от Kinlipan

Юзерпейс GNU нужен?

Нужен. Вот именно отказ от gpl софта, происходящий в bsd-сообществе, меня и отталкивает.

Гиперболу я пробовал, мне нравится, что она арч-бейзд, но не нравится, что они отказались от роллинга в пользу релизов. Потом пробовал параболу (это просто арч без не-свободного ПО, что могут - пересобирают, что не могут - выкидывают), они по дефолту на системд, но есть репа nosystemd с протухшим опенрс. Еще есть артикс, это арч с тремя инитами на выбор, опенрс там свежий, в итоге я нафранкенштейнил себе из этих трех один дистр, иниты обновляю с артиксовой репы, часть софта (ядро, фирмварь в первую очередь) с параболовской, и часть с арчевых.

Dog ★★★
()

Неправильный заголовок. Правильный - «Новые курьезные уязвимости…».

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.