CVE-2026-74686 in Linux
Сводка
по VulDB • 22.08.2026
В ядре Linux была устранена следующая уязвимость:
rqspinlock: Сброс хвоста при сохранении очереди в случае взаимной блокировки (deadlock)
В настоящее время уничтожение очереди ожидающих процессов подавляется для rqspinlock в случаях, когда обнаружена взаимная блокировка. Проверки на наличие deadlock происходят относительно часто (при входе для AA и в течение 1 мс для ABBA), при этом потоки-ожидающие могут не участвовать сценариях блокировки, включающих взаимные блокировки. Таким образом, полезно не очищать очередь и позволить другим ожидающим процессам попытаться получить доступ к блокировке после того, как мы обнаружим deadlock и выйдем из кода.
Однако нам необходимо следовать той же логике, что и ранее для метки waitq_timeout: сбросить хвост (tail), а если это невозможно, соответствующим образом сигнализировать следующему ожидающему процессу. В случае взаимных блокировок этот сигнал просто отметит узел MCS как разблокированный, а в случае таймаута он будет сигнализировать RES_TIMEOUT_VAL. Разница заключается лишь в значении, которое передается, что определяет, остается ли очередь активной или очищается.
Отсутствие сброса хвоста и ожидание следующего ожидающего процесса может привести к ситуациям, когда мы являемся последним ожидающим процессом, а следовательно, следующий ожидающий не появляется, что приводит к периодическим зависаниям на этом пути. Как только следующий ожидающий присоединится, мы будем разблокированы. В теоретическом случае, если следующий ожидающий никогда не присоединится, существует риск бесконечного зависания.
Это может произойти только для взаимных блокировок ABBA, поскольку вход в очередь ожидания защищен проверками AA. Точная последовательность выполнения событий, приводящая к такому сценарию:
CPU 0 удерживает блокировку A. CPU 1 удерживает блокировку B. CPU 2 пытается получить блокировку B и становится ожидающим процессом для B. CPU 0 пытается получить блокировку B. У B установлены биты locked+pending, поэтому CPU 0 добавляется в очередь. CPU 1 пытается получить блокировку A. CPU 0 обнаруживает взаимную блокировку ABBA.
После того как для CPU 0 будет обнаружена взаимная блокировка, он будет ожидать появления следующего ожидающего процесса в очереди для заполнения поля node->next, что приведет к задержкам до тех пор, пока такой процесс не появится.
Исправьте это, изменив логику проверки на наличие deadlock перед меткой waitq_timeout. Было бы целесообразно объединить код для обоих случаев и использовать 'ret' для различения передаваемого значения, но это оставлено как упражнение для будущей задачи рефакторинга, чтобы избежать шума в diff-разнице этого патча.
If you want to get best quality of vulnerability data, you may have to visit VulDB.