diff options
| author | Chuck Lever <[email protected]> | 2021-05-01 19:38:02 +0000 |
|---|---|---|
| committer | Trond Myklebust <[email protected]> | 2021-05-01 23:42:22 +0000 |
| commit | 9e895cd9649abe4392c59d14e31b0f5667d082d2 (patch) | |
| tree | 65806dfb3557a48362d1548ab031ff1498345d32 /drivers/firmware/psci/psci.c | |
| parent | sunrpc: Fix misplaced barrier in call_decode (diff) | |
| download | kernel-9e895cd9649abe4392c59d14e31b0f5667d082d2.tar.gz kernel-9e895cd9649abe4392c59d14e31b0f5667d082d2.zip | |
xprtrdma: Fix a NULL dereference in frwr_unmap_sync()
The normal mechanism that invalidates and unmaps MRs is
frwr_unmap_async(). frwr_unmap_sync() is used only when an RPC
Reply bearing Write or Reply chunks has been lost (ie, almost
never).
Coverity found that after commit 9a301cafc861 ("xprtrdma: Move
fr_linv_done field to struct rpcrdma_mr"), the while() loop in
frwr_unmap_sync() exits only once @mr is NULL, unconditionally
causing subsequent dereferences of @mr to Oops.
I've tested this fix by creating a client that skips invoking
frwr_unmap_async() when RPC Replies complete. That forces all
invalidation tasks to fall upon frwr_unmap_sync(). Simple workloads
with this fix applied to the adulterated client work as designed.
Reported-by: coverity-bot <[email protected]>
Addresses-Coverity-ID: 1504556 ("Null pointer dereferences")
Fixes: 9a301cafc861 ("xprtrdma: Move fr_linv_done field to struct rpcrdma_mr")
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Diffstat (limited to 'drivers/firmware/psci/psci.c')
0 files changed, 0 insertions, 0 deletions
