CVE-2025-38335

Source
https://nvd.nist.gov/vuln/detail/CVE-2025-38335
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-38335.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2025-38335
Downstream
Related
Published
2025-07-10T09:15:28Z
Modified
2025-09-06T13:01:27Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT

When enabling PREEMPTRT, the gpiokeysirqtimer() callback runs in hard irq context, but the inputevent() takes a spinlock, which isn't allowed there as it is converted to a rtspinlock().

[ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 [ 4054.290028] inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 0, name: swapper/0 ... [ 4054.290195] _mightresched+0x13c/0x1f4 [ 4054.290209] rtspinlock+0x54/0x11c [ 4054.290219] inputevent+0x48/0x80 [ 4054.290230] gpiokeysirqtimer+0x4c/0x78 [ 4054.290243] _hrtimerrunqueues+0x1a4/0x438 [ 4054.290257] hrtimerinterrupt+0xe4/0x240 [ 4054.290269] archtimerhandlerphys+0x2c/0x44 [ 4054.290283] handlepercpudevidirq+0x8c/0x14c [ 4054.290297] handleirqdesc+0x40/0x58 [ 4054.290307] generichandledomainirq+0x1c/0x28 [ 4054.290316] gichandle_irq+0x44/0xcc

Considering the gpiokeysirq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context.

Relax the hrtimer not to use the hard context.

References

Affected packages