Исходное сообщение
"Ошибка в ядре Linux 5.12-rc1, приводящая к потере данных в Ф..." Отправлено Аноним, 05-Мрт-21 11:10
Наш же опеннет, никуда не отходя. - В утилите e2fsck, поставляемой в составе пакета e2fsprogs, выявлена уязвимость (CVE-2019-5188), позволяющая добиться выполнения кода злоумышленника при выполнении проверки файловой системы, содержащей специальным образом оформленные каталоги. Наличие уязвимости подтверждено в выпусках с 1.43.3 по 1.45.4. Уязвимость устранена в обновлении e2fsck 1.45.5. В дистрибутивах проблема пока остаётся неисправленной - Йенс Эксбо (Jens Axboe), мэйнтейнер подсистемы блочных устройств, подготовил патч, решающий проблему с файловой системой ext4 в ядре Linux 4.19, которая может привести к повреждению данных. Проблема проявляется при сборке ядра с опцией "CONFIG_SCSI_MQ_DEFAULT=y", которая выставляется по умолчанию начиная с версии 4.19. Необходимым условием также является работа без планировщика ввода-вывода (/sys/devices/virtual/block/*/queue/scheduler содержит значение "none"). Так как источник проблемы не специфичен для ext4 и присутствует в слое разделения очередей для блочных устройств ("blk-mq"), то теоретически проблема могла затрагивать и другие файловые системы, но в силу популярности проявление проблемы пока зафиксировано только для Ext4. - Проблема с потерей данных на разделах с файловой системой Ext4, о которой сообщалось несколько дней назад, оказалась не специфична для файловой системы Ext4. Проблема присутствует в коде подсистемы md и может привести к непредсказуемому нарушению целостности файловой системы при изменении или удалении файлов. Проблема проявляется только для ФС, установленных поверх RAID 0 и примонтированных с опцией DISCARD. Ошибка проявляется в ветках ядра 4.0 и 3.14 LTS, начиная с выпусков 4.0.2 и 3.14.41. - В ядре Linux выявлены две неприятные ошибки: Начиная с выпуска 3.14 и заканчивая 3.18, т.е. с января по октябрь 2014 года, в ядре Linux присутствовала неприятная ошибка в реализации вызова futex_wait, которая могла приводить к непредсказуемому зависанию процессов на серверах с процессорами на базе микроархитектуры Intel Haswell, в том числе используемых в облаках Amazon.Данная ошибка является причиной замешательства многих программистов, которые месяцами пытались найти ошибку в своих приложениях, зависающих при непонятных обстоятельствах. Причиной зависания была взаимная блокировка в ядре из-за которой фьютекс (futex) оставался навсегда в состоянии блокировки, несмотря на его фактическое освобождение. Проблема усугубляется тем, что связанная с проблемой функциональность была перенесена в ядро, поставляемое в дистрибутиве Red Hat Enterprise Linux и присутствует как минимум в выпусках RHEL/CentOS 6.6 и 7.1. - Ты сюда знания получать ходишь или подзюбить?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Наш же опеннет, никуда не отходя. > - > В утилите e2fsck, поставляемой в составе пакета e2fsprogs, выявлена уязвимость (CVE-2019-5188), > позволяющая добиться выполнения кода злоумышленника при выполнении проверки файловой > системы, содержащей специальным образом оформленные каталоги. Наличие уязвимости подтверждено > в выпусках с 1.43.3 по 1.45.4. Уязвимость устранена в обновлении e2fsck > 1.45.5. В дистрибутивах проблема пока остаётся неисправленной > - > Йенс Эксбо (Jens Axboe), мэйнтейнер подсистемы блочных устройств, подготовил патч, решающий > проблему с файловой системой ext4 в ядре Linux 4.19, которая может > привести к повреждению данных. Проблема проявляется при сборке ядра с опцией > "CONFIG_SCSI_MQ_DEFAULT=y", которая выставляется по умолчанию начиная с версии 4.19. > Необходимым условием также является работа без планировщика ввода-вывода (/sys/devices/virtual/block/*/queue/scheduler > содержит значение "none"). > Так как источник проблемы не специфичен для ext4 и присутствует в слое > разделения очередей для блочных устройств ("blk-mq"), то теоретически проблема могла затрагивать > и другие файловые системы, но в силу популярности проявление проблемы пока > зафиксировано только для Ext4. > - > Проблема с потерей данных на разделах с файловой системой Ext4, о которой > сообщалось несколько дней назад, оказалась не специфична для файловой системы Ext4. > Проблема присутствует в коде подсистемы md и может привести к непредсказуемому > нарушению целостности файловой системы при изменении или удалении файлов. Проблема проявляется > только для ФС, установленных поверх RAID 0 и примонтированных с опцией > DISCARD. > Ошибка проявляется в ветках ядра 4.0 и 3.14 LTS, начиная с выпусков > 4.0.2 и 3.14.41. > - > В ядре Linux выявлены две неприятные ошибки: > Начиная с выпуска 3.14 и заканчивая 3.18, т.е. с января по октябрь > 2014 года, в ядре Linux присутствовала неприятная ошибка в реализации вызова > futex_wait, которая могла приводить к непредсказуемому зависанию процессов на серверах > с процессорами на базе микроархитектуры Intel Haswell, в том числе используемых > в облаках Amazon.Данная ошибка является причиной замешательства многих программистов, > которые месяцами пытались найти ошибку в своих приложениях, зависающих при непонятных > обстоятельствах. Причиной зависания была взаимная блокировка в ядре из-за которой фьютекс > (futex) оставался навсегда в состоянии блокировки, несмотря на его фактическое освобождение. > Проблема усугубляется тем, что связанная с проблемой функциональность была перенесена > в ядро, поставляемое в дистрибутиве Red Hat Enterprise Linux и присутствует > как минимум в выпусках RHEL/CentOS 6.6 и 7.1. > - > Ты сюда знания получать ходишь или подзюбить?
	Введите код, изображенный на картинке: