Выпуск системной библиотеки Glibc 2.33

Kate

Administrator
Команда форума
После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.33, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017. В состав нового выпуска включены исправления от 72 разработчиков.

Из реализованных в Glibc 2.33 улучшений можно отметить:

  • В компоновщике (dynamic linker), отвечающем за динамическую загрузку и связывание разделяемых библиотек при запуске программы, реализована поддержка загрузки оптимизированных реализаций разделяемых объектов из подкаталогов glibc-hwcaps, созданных в областях ФС, просматриваемых при поиске библиотек. В настоящий момент реализованы подкаталоги "x86-64-v2", "x86-64-v3" и "x86-64-v4" для архитектуры x86_64-linux-gnu, "power9" и "power10" для архитектуры powerpc64le-linux-gnu, "z13", "z14" и "z15" для s390x-linux-gnu. В случае архитектуры x86_64-linux-gnu имя подкаталога выбирается в зависимости от версии psABI.
  • В компоновщик также добавлены флаги: "--list-tunables" для вывода всех поддерживаемых внутренних настроек поведения Glibc, "--argv0" для изменения строки argv[0], в которой содержится название текущего исполняемого файла, и "--help" для вывода подсказки и информации о проверяемых файловых путях.
  • Добавлена функция mallinfo2, которая также как mallinfo выводит статистику о распределении памяти, но с большим размером полей, позволяющим выводить значения, не умещающиеся в тип integer.
  • Добавлен заголовочный файл <sys/platform/x86.h> с макросами для проверки функциональных возможностей x86 CPU.
  • Добавлена поддержка 32-разрядных систем на базе архитектуры набора команд RISC-V (ISA rv32imac, rv32imafdc и rv32imafdc). Для работы 32-разрядного порта RISC-V требуется как минимум ядро Linux 5.4, GCC 7.1 и binutils 2.28. 64-разрядный порт RISC-V поддерживается начиная с Glibc 2.27.
  • Добавлен новый режим защиты "_FORTIFY_SOURCE=3", предназначенный для определения во время компиляции и во время работы возможных переполнений буфера при выполнении строковых функций, определённых в заголовочном файле string.h. Отличие от режима "_FORTIFY_SOURCE=2" сводится к дополнительным проверкам, которые потенциально могут приводить к снижению производительности. На стороне компилятора режим пока поддерживается только в LLVM 9 (в GCC ещё не реализован).
  • Объявлена устаревшей функция mallinfo. Удалена функция vtimes (оставлена заглушка для сохранения совместимости) и заголовочный файл <sys/vtimes.h>.
  • При вызове dlopen из программ со статическим связыванием прекращена загрузка альтернативных библиотек из подкаталогов HWCAP. В будущих выпусках glibc решено прекратить загрузку разделяемых объектов из подкаталогов tls. Приложениям следует перейти на новый механизм glibc-hwcaps.
  • В Linux прекращена корректировка прав доступа к устройствам терминала силами Glibc. Администраторам теперь нужно следить за режимом доступа к /dev/pts самостоятельно, но изменение во многом формальность, так как в большинстве систем давно выставляются необходимые значения (группа tty, право чтения/записи для пользователя и право записи для группы).
  • Функции posix_openpt и getpt больше не пытаются использовать устаревшие псевдотерминалы в Linux и при наличии /dev/ptmx считают псевдо-ФС devpts примонтированной к /dev/pts.
  • Устранены уязвимости:
    • CVE-2019-25013 - переполнение буфера при обработке в функции iconv строки в кодировке EUC-KR, включающей некорректные многобайтовые последовательности (например, echo -en "\x00\xfe" | iconv -c -f EUC-KR -t "UTF-8"). По мнению инженеров из Red Hat эффект от уязвимости ограничивается крахом, а проблема проявляется только при явном использовании кодировки EUC-KR.
    • CVE-2021-3326 - крах из-за срабатывания assert-проверки при преобразовании символов ISO-20220-JP-3 при помощи функции iconv из-за выхода результирующей строки за конец буфера на два символа.
    • CVE-2020-27618 - зацикливание при обработке в iconv определённых последовательностей символов в кодировках IBM1364, IBM1371, IBM1388, IBM1390 и IBM1399.
    • CVE-2020-29562 - крах из-за срабатывания assert-проверки при обработке в функции iconv некорректных символов в кодировке UCS4.
Источник статьи: https://www.opennet.ru/opennews/art.shtml?num=54508
 
Сверху