bbc0979...
by
Dan Carpenter <email address hidden>
crypto: ccp - fix resource leaks in ccp_run_aes_gcm_cmd()
There are three bugs in this code:
1) If we ccp_init_data() fails for &src then we need to free aad.
Use goto e_aad instead of goto e_ctx.
2) The label to free the &final_wa was named incorrectly as "e_tag" but
it should have been "e_final_wa". One error path leaked &final_wa.
3) The &tag was leaked on one error path. In that case, I added a free
before the goto because the resource was local to that block.
Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Reported-by: "minihanshen(沈明航)" <email address hidden>
Signed-off-by: Dan Carpenter <email address hidden>
Reviewed-by: John Allen <email address hidden>
Tested-by: John Allen <email address hidden>
Signed-off-by: Herbert Xu <email address hidden>
(cherry picked from commit 505d9dcb0f7ddf9d075e729523a33d38642ae680)
CVE-2021-3764
CVE-2021-3744
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
84ce2c1...
by
Jason Gunthorpe <email address hidden>
RDMA/ucma: Rework ucma_migrate_id() to avoid races with destroy
ucma_destroy_id() assumes that all things accessing the ctx will do so via
the xarray. This assumption violated only in the case the FD is being
closed, then the ctx is reached via the ctx_list. Normally this is OK
since ucma_destroy_id() cannot run concurrenty with release(), however
with ucma_migrate_id() is involved this can violated as the close of the
2nd FD can run concurrently with destroy on the first:
_destroy_id() wait_for_completion()
// boom, ctx was freed
The ctx->file must be modified under the handler and xa_lock, and prior to
modification the ID must be rechecked that it is still reachable from
cur_file, ie there is no parallel destroy or migrate.
To make this work remove the double locking and streamline the control
flow. The double locking was obsoleted by the handler lock now directly
preventing new uevents from being created, and the ctx_list cannot be read
while holding fgets on both files. Removing the double locking also
removes the need to check for the same file.
Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()")
Link: https://<email address hidden>
Reported-and-tested-by: <email address hidden>
Signed-off-by: Jason Gunthorpe <email address hidden>
(cherry picked from commit f5449e74802c1112dea984aec8af7a33c4516af1)
CVE-2020-36385
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
fa4ea9b...
by
Jason Gunthorpe <email address hidden>
RDMA/ucma: Fix the locking of ctx->file
ctx->file is changed under the file->mut lock by ucma_migrate_id(), which
is impossible to lock correctly. Instead change ctx->file under the
handler_lock and ctx_table lock and revise all places touching ctx->file
to use this locking when reading ctx->file.
Link: https://<email address hidden>
Signed-off-by: Leon Romanovsky <email address hidden>
Signed-off-by: Jason Gunthorpe <email address hidden>
(backported from commit 09e328e47a695b0d346598f5d6593ee598e64885)
[cascardo: commit 95fe51096b7adf1d1e7315c49c75e2f75f162584 moved the
file locks from ucma_cleanup_mc_events callers to inside it, keep it
out of the function]
CVE-2020-36385
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
64e885c...
by
Jason Gunthorpe <email address hidden>
RDMA/cma: Add missing locking to rdma_accept()
In almost all cases rdma_accept() is called under the handler_mutex by
ULPs from their handler callbacks. The one exception was ucma which did
not get the handler_mutex.
To improve the understand-ability of the locking scheme obtain the mutex
for ucma as well.
This improves how ucma works by allowing it to directly use handler_mutex
for some of its internal locking against the handler callbacks intead of
the global file->mut lock.
There does not seem to be a serious bug here, other than a DISCONNECT event
can be delivered concurrently with accept succeeding.
Link: https://<email address hidden>
Signed-off-by: Leon Romanovsky <email address hidden>
Signed-off-by: Jason Gunthorpe <email address hidden>
(cherry picked from commit d114c6feedfe0600c19b9f9479a4026354d1f7fd)
CVE-2020-36385
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
1 branch
proposed for merging into this one.
