В ядре Linux устранена следующая уязвимость:
предохранитель: исправлен отсутствующий барьер при проверке готовности к вводу в эксплуатацию.
Fuse_block_alloc() считывает fch->initialized, а затем fch->io_uring.
fch->io_uring устанавливается до fch->initialized, упорядочивается с помощью smp_wmb()
в Fuse_chan_set_intialized(), но у Fuse_block_alloc() нет соответствия
прочитать барьер между двумя нагрузками. Это может привести к тому, что процессор обнаружит fch->initialized=1, но fch->io_uring=0,
и пропустить проверку, которая блокирует распределение запросов до тех пор, пока не будет выполнено io-uring.
очереди готовы. Это может вновь привести к тупику инверсии порядка блокировки.
этот коммит 3393ff964e0f предотвращает.
Добавьте барьер smp_rmb() в пару с smp_wmb() в
Fuse_chan_set_initialized(), чтобы предотвратить это.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: fuse: fix missing barrier when checking io-uring readiness fuse_block_alloc() reads fch->initialized and then fch->io_uring. fch->io_uring is set before fch->initialized, ordered by the smp_wmb() in fuse_chan_set_intialized(), but fuse_block_alloc() has no matching read barrier between the two loads. This may lead a CPU to observe fch->initialized=1 but fch->io_uring=0, and skip the check that blocks request allocation until the io-uring queues are ready. This can reintroduce the lock-order inversion deadlock that commit 3393ff964e0f prevents. Add an smp_rmb() barrier to pair with the smp_wmb() in fuse_chan_set_initialized() to prevent this.