Разработчик Debian Лука Боккасси анонсировал переход Debian к использованию tmpfs в /tmp и к очистке /tmp и /var/tmp по таймеру по умолчанию, начиная с Debian 13 “Trixie”.

В новых системах файлы в /tmp будут либо исчезать вместе с прежним экземпляром tmpfs в памяти после рестарта, либо будут удаляться ежедневно по таймеру, если они старше 10 дней, а файлы в /var/tmp будут удаляться только ежедневно по таймеру, если они старше 30 дней. Пакеты openssh и tmux были модифицированы с целью сохранения своих временных файлов в /var/tmp в качестве исключения. В системах, которые будут обновляться до Debian 13 “Trixie”, старое поведение /var/tmp сохранится.

В то время, как в большинстве других дистрибутивов давно перешли на использование tmpfs в /tmp, в Debian не спешили этого делать. Сейчас разработчики Debian (Michael Biebl и Luca Boccassi) возобновили одну из таких дискуссий 2020 года, в которой разработчик из Canonical (Eric Desrochers) пожаловался на проблему несоответствия тогдашней реализации /var/tmp в Debian тому, как работает systemd, несмотря на то, что патч был опубликован ещё в 2012 году. Таким образом, было принято решение привести поведение системы при работе с этими директориями к общепринятому в systemd и в большинстве других дистрибутивов.

>>> Подробности

Инженер из Intel, Ноах Голдштейн, оптимизировал функцию memset() в библиотеке glibc. Данная оптимизация даёт прирост в производительности порядка 7.5% на десктопных версиях процессоров архитектур Skylake-X и Ice Lake. У серверных версий прирост в производительности немного ниже, прежде всего из-за более низкой общей производительности одиночного ядра.

В прежней реализации функции memset() использовалась ассемблерная инструкция rep stosb. До недавнего времени эта инструкция работала достаточно быстро, за счёт внутрипроцессорной оптимизации zero-over-zero writeback. Однако в этой оптимизации была найдена потенциальная уязвимость, которая может привести к атаке по побочному каналу. В результате оптимизация zero-over-zero writeback была отменена, что и привело к ухудшению производительности rep stosb. В новой версии memset() инструкция rep stosb всё ещё используется, но при выполнении более строгих условий.

Что именно изменилось, можно понять по изменению следующего комментария в коде, который описывает подробности реализации memset()

Прежняя версия описания:

/* memset is implemented as:
   1. Use overlapping store to avoid branch.
   2. If size is less than VEC, use integer register stores.
   3. If size is from VEC_SIZE to 2 * VEC_SIZE, use 2 VEC stores.
   4. If size is from 2 * VEC_SIZE to 4 * VEC_SIZE, use 4 VEC stores.
   5. On machines ERMS feature, if size is greater or equal than
      __x86_rep_stosb_threshold then REP STOSB will be used.
   6. If size is more to 4 * VEC_SIZE, align to 4 * VEC_SIZE with
      4 VEC stores and store 4 * VEC at a time until done.  */

Новая версия описания:

/* memset is implemented as:
   1. Use overlapping store to avoid branch.
   2. If size is less than VEC, use integer register stores.
   3. If size is from VEC_SIZE to 2 * VEC_SIZE, use 2 VEC stores.
   4. If size is from 2 * VEC_SIZE to 4 * VEC_SIZE, use 4 VEC stores.
   5. If size is more to 4 * VEC_SIZE, align to 1 * VEC_SIZE with
      4 VEC stores and store 4 * VEC at a time until done.
   6. On machines ERMS feature, if size is range
	  [__x86_rep_stosb_threshold, __x86_memset_non_temporal_threshold)
	  then REP STOSB will be used.
   7. If size >= __x86_memset_non_temporal_threshold, use a
	  non-temporal stores.  */

>>> Подробности

Агентство по кибербезопасности и защите инфраструктуры (U.S. Cybersecurity and Infrastructure Security Agency (CISA)) добавило в свой каталог активно используемых уязвимостей недавно найденную проблему в ядре Linux: CVE-2024-1086 Linux Kernel Use-After-Free Vulnerability.

Речь идёт о компоненте nf_tables, внутри встроенного в ядро фаервола netfilter, которая может быть эксплуатирована для эскалации локальных привилегий. Ошибка связана с неправильным взаимодействием функций nft_verdict_init() и nf_hook_slow(), которое приводит к двойному освобождению памяти.

Рекомендовано срочно обновиться или откатить ядро до версии перед коммитом f342de4e2f33e0e39165d8639387aa6c19dff660

>>> Подробности