Баг в Linux 5.1 приводил к потере данных — корректирующий патч уже вышел

    Пару недель назад в версии ядра Linux 5.1 обнаружили баг, который приводил к потере данных на SSD. Недавно разработчики выпустили корректирующий патч Linux 5.1.5, который залатал «брешь».

    Обсуждаем, в чем была причина.


    / Unsplash / Glen Carrie

    Что за баг


    В начале года разработчики внесли ряд изменений в ядро Linux 5.1. После этого на системах с SSD от компании Samsung, которые используют шифрование dm-crypt/LUKS c device-mapper/LVM, начала проявляться ошибка, приводящая к потере данных. Но о проблеме стало известно только в середине мая — тогда же её начали активно обсуждать на тематических форумах.

    Известно как минимум о двух людях, столкнувшихся с багом, — это участник рассылки LKML Майкл Ласс (Michael Laß), который впервые сообщил о проблеме, и пользователь ArchLinux.

    Майкл запустил команду fstrim, которая говорит накопителю, какие блоки данных больше не используются, для смонтированного тома btrfs. После он получил следующие системные сообщения:

    attempt to access beyond end of device
    sda1: rw=16387, want=252755893, limit=250067632
    BTRFS warning (device dm-5): failed to trim 1 device(s), last error -5
    
    BTRFS warning (device dm-5): csum failed root 257 ino 16634085 off 21504884736 csum 0xd47cc2a2 expected csum 0xcebd791b mirror 1
    

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

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

    В чем причина


    Проблема заключалась в подсистеме device mapper (DM), задача которой — создавать виртуальные блочные устройства. Она как раз используется для реализации менеджера логических томов LVM, программного RAID и системы шифрования дисков dm-crypt.

    «Команда fstrim помечала слишком большое количество блоков за раз без учета предела max_io_len_target_boundary. В результате освобождались те сегменты памяти, которые до сих пор используются, — комментирует Сергей Белкин, начальник отдела развития 1cloud.ru. — Поскольку ошибка была связана с device mapper, в теории потеря данных могла произойти на любой файловой системе».

    Патч


    Патч для бага разработчики ядра выпустили в конце мая. Были изменены всего четыре строчки в файле drivers/md/dm.c. Соответствующие изменения также внесли в грядущее ядро Linux 5.2 (добавленные и удаленные строки отмечены знаками «+» и «-» соответственно):

    @@ -1467,7 +1467,7 @@ static unsigned get_num_write_zeroes_bios(struct dm_target *ti)
     static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *ti,
     				       unsigned num_bios)
     {
    - unsigned len = ci->sector_count;
    +  unsigned len;
     
    @@ -1478,6 +1478,8 @@ static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *
     	if (!num_bios)
     		return -EOPNOTSUPP;
     
    +  len = min((sector_t)ci->sector_count, max_io_len_target_boundary(ci->sector, ti));
    +
     	__send_duplicate_bios(ci, ti, num_bios, &len);
     
     	ci->sector += len;
    

    Патч уже применили разработчики дистрибутивов ArchLinux/Manjaro и Fedora. Дистрибутив Ubuntu ошибка не затронула, так как его не переводили на версию ядра Linux 5.1.


    / Flickr / Andy Melton / CC BY-SA

    Исключить ситуацию с потерей данных можно и не устанавливая патч. Достаточно отключить сервис fstrim.service/timer с помощью команд:

    systemctl disable fstrim.timer
    systemctl stop fstrim.timer
    

    Еще вариант — переименовать исполняемый файл fstrim или убрать флаг discard при монтировании fstab. Еще можно выключить режим allow-discards в LUKS через dmsetup. Однако все эти методы не более чем временные и не решают сути проблемы.

    Не первый раз


    Это не первый случай, когда коммит в ядре Linux приводит к ситуациям с memory corruption. Похожая история случалась в версии Linux 4.19 — тогда оказались виноваты планировщики ввода/вывода BLK-MQ. Проблема проявлялась при сборке ядра с опцией CONFIG_SCSI_MQ_DEFAULT=y, выставляемой по умолчанию. В некоторых случаях данные тома оказывались повреждены.

    sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107
    sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107
    

    Наиболее часто проблема проявлялась с EXT4, но в теории могла затрагивать и другие файловые системы.

    Тогда один из мейнтейнеров ядра подготовил небольшой фикс, который решал проблему. Однако этот же самый баг позже обнаружили в билде Linux 4.20. Окончательно избавиться от него удалось в конце декабря 2018 с новым глобальным обновлением.

    Наши дополнительные ресурсы и источники:

    Резервное копирование файлов: как подстраховаться от потери данных
    Минимизация рисков: как не потерять ваши данные
    Backup&Recovery: поточная и умная дедупликация, снапшоты и вторичное хранение
    Как сэкономить с помощью прикладного программного интерфейса
    DevOps в облачном сервисе на примере 1cloud.ru
    Эволюция архитектуры облака 1cloud

    Как у нас все устроено: дайджест от 1cloud
    Потенциальные атаки на HTTPS и способы защиты от них
    • +19
    • 10,4k
    • 4
    1cloud.ru
    241,14
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией

    Комментарии 4

      +1
      Не понятно почему ошибка проявлялось только на SSD Samsung.
        +4
        Потому что это чья-то отсебятина, которую копируют по цепочке из статьи в статью по этой проблеме. В коммите фикса ни слова о каком-либо бренде или вообще типе накопителя.

        Для воспроизведения проблемы достаточно было иметь device mapper-based блочное устройство, поддерживающее TRIM, у которого непоследовательно были расположены блоки, например LV с количеством сегментов более одного. Иными словами фрагментированные LV и thin-provisioned тома могли быть так же повреждены даже если они лежали на жёстких дисках.
          +1
          Майкл Ласс (который собственно это дело и обнаружил) в баг-репорте на сайте ArchLinux пишет, что проблема затрагивала пользователей, использующих SSD от Самсунга
            0
            Возможно SSD от самсунга имеются у большего числа пользователей. У меня у самого, например, почти все SSD от самсунга.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое