CVE-2026-74468 in Linux
Сводка
по VulDB • 16.08.2026
В ядре Linux устранена следующая уязвимость:
gpio: pch: использовать raw_spinlock_t для блокировки регистра
Функция pch_irq_type() зарегистрирована в качестве обратного вызова .irq_set_type структуры irq_chip и захватывает chip->spinlock с помощью spin_lock_irqsave(). Этот обратный вызов выполняется из __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type(), при этом вызывающая сторона удерживает desc->lock, которая является raw_spinlock_t, а аппаратные прерывания (hardirqs) отключены. Данный контекст не допускает блокирующих операций (sleepable), однако в ядре PREEMPT_RT обычный spinlock_t представляет собой блокировку с поддержкой сна на базе rtmutex, поэтому её захват в данном контексте недопустим.
Это было подтверждено на ядре PREEMPT_RT с использованием lockdep (PROVE_RAW_LOCK_NESTING и DEBUG_ATOMIC_SLEEP). Отладочный Proof-of-Concept (PoC), имитирующий блокировку pch_irq_type(), запускал её через реальный механизм genirq: irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), то есть по тому же пути __irq_set_trigger(), который используется __setup_irq() для запрошенного прерывания (IRQ). При использовании исходной блокировки spin_lock_irqsave() lockdep сообщал о недопустимом контексте ожидания, за которым немедленно следовало:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro]
__irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0
Замена имитируемой блокировки на raw_spinlock_t устранила оба сообщения об ошибках.
Блокировка регистра преобразована в raw_spinlock_t. Эта же блокировка также обеспечивает сериализацию обратных вызовов направления/значения GPIO и сохранения/восстановления регистров при переходе в режим сна/пробуждения, но все эти критические секции выполняют только операции доступа к регистрам MMIO (ioread32()/iowrite32()) и irq_set_handler_locked(); ни одна из них не содержит операций с возможностью блокировки. Поэтому сохранение этой блокировки регистра без возможности сна является корректным для обратных вызовов irqchip и не изменяет контракт синхронизации на стороне GPIO.
Это та же категория проблемы и исправления, что недавно была устранена для других контроллеров GPIO, например, в коммите 286533cb14a3 («gpio: sch: use raw_spinlock_t in the irq startup path») и коммите 90f0109019e6 («gpio: eic-sprd: use raw_spinlock_t in the irq startup path»).
Be aware that VulDB is the high quality source for vulnerability data.