CVE-2026-31647: idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling
In the Linux kernel, the following vulnerability has been resolved:
idpf: fix PREEMPTRT raw/bh spinlock nesting for async VC handling
Switch from using the completion's raw spinlock to a local lock in the idpfvcxn struct. The conversion is safe because complete/all() are called outside the lock and there is no reason to share the completion lock in the current logic. This avoids invalid wait context reported by the kernel due to the async handler taking BH spinlock:
[ 805.726977] ============================= [ 805.726991] [ BUG: Invalid wait context ] [ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE [ 805.727026] ----------------------------- [ 805.727038] kworker/u261:0/572 is trying to lock: [ 805.727051] ff190da6a8dbb6a0 (&vportconfig->macfilterlistlock){+...}-{3:3}, at: idpfmacfilterasynchandler+0xe9/0x260 [idpf] [ 805.727099] other info that might help us debug this: [ 805.727111] context-{5:5} [ 805.727119] 3 locks held by kworker/u261:0/572: [ 805.727132] #0: ff190da6db3e6148 ((wqcompletion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: processonework+0x4b5/0x730 [ 805.727163] #1: ff3c6f0a6131fe50 ((workcompletion)(&(&adapter->mbxtask)->work)){+.+.}-{0:0}, at: processonework+0x1e5/0x730 [ 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at: idpfrecvmbmsg+0xc8/0x710 [idpf] [ 805.727218] stack backtrace: ... [ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpfmbxtask [idpf] [ 805.727247] Call Trace: [ 805.727249] <TASK> [ 805.727251] dumpstacklvl+0x77/0xb0 [ 805.727259] lockacquire+0xb3b/0x2290 [ 805.727268] ? irqworkqueuelocal+0x59/0x130 [ 805.727275] lockacquire+0xc6/0x2f0 [ 805.727277] ? idpfmacfilterasynchandler+0xe9/0x260 [idpf] [ 805.727284] ? printk+0x5b/0x80 [ 805.727290] rawspinlockbh+0x38/0x50 [ 805.727298] ? idpfmacfilterasynchandler+0xe9/0x260 [idpf] [ 805.727303] idpfmacfilterasynchandler+0xe9/0x260 [idpf] [ 805.727310] idpfrecvmbmsg+0x1c8/0x710 [idpf] [ 805.727317] processonework+0x226/0x730 [ 805.727322] workerthread+0x19e/0x340 [ 805.727325] ? pfxworkerthread+0x10/0x10 [ 805.727328] kthread+0xf4/0x130 [ 805.727333] ? pfxkthread+0x10/0x10 [ 805.727336] retfromfork+0x32c/0x410 [ 805.727345] ? pfxkthread+0x10/0x10 [ 805.727347] retfromforkasm+0x1a/0x30 [ 805.727354] </TASK>
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.83 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.23 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.19.13 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 7.0.0-1006.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.85-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.19.13-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.116-1Fixed in 7.2.15-1Fixed in 7.3.4-1 - Compensating control
In the Linux kernel idpf driver, switch async VC handling from the completion's raw spinlock to a local lock in the idpf_vc_xn struct; keep complete() and complete_all() calls outside the lock.
Event History
Frequently Asked Questions
What access would an attacker need to exploit this issue?
The CVSS vector indicates local access and low privileges are required. No user interaction is required.
What is the expected security impact?
The reported impact is limited to availability: exploitation may cause a denial of service. The provided vector reports no confidentiality or integrity impact.
Which systems are most relevant to investigate?
Systems using the Linux kernel idpf driver with PREEMPT_RT and asynchronous virtual-channel handling are implicated. The supplied diagnostic shows the failure occurring in an idpf worker while handling MAC filter configuration.
How can I identify a possible occurrence?
Check kernel logs for an "BUG: Invalid wait context" report involving the idpf module, particularly idpf_mac_filter_async_handler and mac_filter_list_lock. The example report identifies a kworker attempting to take that lock in an invalid context.
Are fixes available?
The issue is described as resolved, and three stable kernel commit references are provided. The supplied data does not identify the kernel versions containing those fixes.