summaryrefslogtreecommitdiffstats
path: root/include/uapi
diff options
context:
space:
mode:
authorDani Liberman <dliberman@habana.ai>2021-12-27 21:18:03 +0200
committerOded Gabbay <ogabbay@kernel.org>2022-02-28 14:22:04 +0200
commitb32cd10480ebcfd66c3f7ae9fece951e5b5b35ae (patch)
tree40605ebf98dbdcb4f361e5ed98719b6c2df48116 /include/uapi
parenta8076c47f6f78e5709d3a6b89c146c2706637f02 (diff)
downloadlinux-b32cd10480ebcfd66c3f7ae9fece951e5b5b35ae.tar.gz
linux-b32cd10480ebcfd66c3f7ae9fece951e5b5b35ae.tar.bz2
linux-b32cd10480ebcfd66c3f7ae9fece951e5b5b35ae.zip
habanalabs: fix race when waiting on encaps signal
Scenario: 1. CS which is part of encaps signal has been completed and now executing kref_put to its encaps signal handle. The refcount of the handle decremented to 0, and called the encaps signal handle release function - hl_encaps_handle_do_release. 2. At this point the user starts waiting on the signal, and finds the encaps signal handle in the handlers list and increment the habdle refcount to 1. 3. Immediately after, hl_encaps_handle_do_release removed the handle from the list and free its memory. 4. Wait function using the handle although it has been freed. This scenario caused the slab area which was previously allocated for the handle to be poison overwritten which triggered kernel bug the next time the OS needed to allocate this slab. Fixed by getting the refcount of the handle only in case it is not zero. Signed-off-by: Dani Liberman <dliberman@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Diffstat (limited to 'include/uapi')
0 files changed, 0 insertions, 0 deletions