CVE-2026-74646: misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke
In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke
When an invoke is interrupted by a signal, waitforcompletioninterruptible() returns -ERESTARTSYS and fastrpcinternalinvoke() moves every buffer from fl->mmaps onto cctx->invokeinterruptedmmaps. This listdel()/listaddtail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpcreqmmap() and fastrpcreqmunmap() everywhere else.
Take fl->lock around the move, matching every other fl->mmaps accessor.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems using the Linux kernel fastrpc subsystem may be exposed when an invoke is interrupted by a signal while buffer mappings are being moved. The relevant contention is with concurrent fastrpc mmap or munmap activity on the same file context.
What conditions are required to trigger the issue?
An invoke must be interrupted such that wait_for_completion_interruptible() returns -ERESTARTSYS. During the resulting move of buffers from fl->mmaps to the interrupted-invoke list, concurrent access to fl->mmaps can race because the move was not serialized by fl->lock.
How can I determine whether a kernel includes the fix?
Inspect the fastrpc interrupted-invoke handling in fastrpc_internal_invoke(). The corrected code holds fl->lock around the walk that removes entries from fl->mmaps and adds them to cctx->invoke_interrupted_mmaps; the referenced stable commits contain the fix.