В ядре Linux устранена следующая уязвимость: btrfs: исправить рикрит bitfield написать в btrfs_clear_space_info_full() Из документа памяти-…

В ядре Linux устранена следующая уязвимость: btrfs: исправить рикрит bitfield написать в btrfs_clear_space_info_full() Из документа памяти-барьеров.txt о порядке барьера памяти гарантии: (*) Эти гарантии не распространяются на битфилды, потому что компиляторы часто генерировать код для изменения их с использованием неатомного чтения-изменения-записи Последовательности. Не пытайтесь использовать битфилды для синхронизации параллельного Алгоритмы. (*) Даже в тех случаях, когда битовые поля защищены замками, все поля в данном битфилде должен быть защищен одним замком. Если два поля в данном битфилде защищены различными замками, компилятор неатомные последовательности чтения-изменения-записи могут вызвать обновление до одного поле, чтобы испортить ценность соседнего поля. btrfs_space_info имеет битфилд общего базового слова, состоящего из поля полные, chunk_allock, и флеш: Построить btrfs_space_info { структурировать btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * родительский; /* 8 8 */ ... int зажим; /* 172 4 */ неподписанный полный:1; /* 176: 0 4 */ неподписанный int chunk_alloc:1; /* 176: 1 4 */ Неподписанный смыв:1; /* 176: 2 4 */ ... Поэтому, чтобы быть в безопасности от параллельных чтения-изменить-писать, теряя запись к один из членов битфилда, защищенный замком, все пишет всем Битфилды должны использовать замок. Они почти повсеместно делают, за исключением btrfs_clear_space_info_full(), который итерирует над space_infos и записывает найдено>full = 0 без замка. Представьте, что у нас есть одна нить, завершающая транзакцию, в которой мы закончил удаление block_group и таким образом звоните btrfs_clear_space_info_full() при одновременном восстановлении данных Билетная инфраструктура работает do_async_reclaim_data_space(): Т1 Т2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 Читать: полный:0, chunk_alloc:0, флеш:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->блокировка); if(list_empty(tickets)) space_info->flush = 0; ЧИТАЙТЕ: полный: 0, chunk_alloc:0, флеш:1 MOD/WRITE: полный: 0, chunk_alloc:0, fsh:0 spin_unlock(&space_info->lock); возврат; МОД/ЗВИМАЕ: полный:0, кусок_аллок:0, флеш:1 и теперь data_sinfo->fflush является 1, но работник возврата вышел. Это ломает инвариант, что смыв 0, если нет работы в очереди или Бегущий. Как только этот инвариант нарушается, будущие ассигнования, которые идут в __reserve_bytes() добавит билеты в space_info->билеты, но будет см. space_info->flush установлен на 1 и не выставлять очередь на работу. После этого, они будут блокировать навсегда на получившемся билете, так как это теперь невозможно Чтобы снова пнуть работника. Я также подтвердил, взглянув на сборку пораженного ядра, что Он выполняет операции RMW. Например, чтобы установить флеш (3-й) бит к 0, Сборация представляет собой: и b $0xfb,0x60(%rbx) и аналогично для установки полного (1-й) бит к 0: и b $0xfe,-0x20(%rax) Так что я думаю, что это действительно ошибка в практических системах. Я наблюдал несколько систем в этом то же состоянии, но в настоящее время не в состоянии Воспроизвести его. Вместо того, чтобы оставлять этот фугу лежать в будущем, возьмите преимущество того, что в управлении есть место в порядке в любом случае, и что он уже довольно большой и просто меняет трех членов bitfield на Булс. Это позволяет избежать записи на space_info->full, оказывая какое-либо влияние на ---усеченный---