diff options
| author | Jacob Moroni <jmoroni@google.com> | 2026-10-06 15:29:08 +0000 |
|---|---|---|
| committer | Leon Romanovsky <leon@kernel.org> | 2026-10-11 09:20:01 -0400 |
| commit | d37e98844afea39a9614cac0de837701263c90f7 (patch) | |
| tree | ddbb0e5805a55882cb7a7ee0f6e16a3677b8f16e /include/linux/platform_data | |
| parent | 3255d6b83491574b115806ec958d8f6ca090fa9c (diff) | |
| download | linux-next-d37e98844afea39a9614cac0de837701263c90f7.tar.gz linux-next-d37e98844afea39a9614cac0de837701263c90f7.zip | |
RDMA/core: Clear driver_udata before destroying objects in rdma_core
When uobject creation fails while copying user output data (i.e.,
after the HW object has been created), it calls
rdma_alloc_abort_uobject() with hw_obj_valid=true which then
invokes the object's destroy callback, but passes the
uverbs_attr_bundle from the original creation command.
The issue is that drivers are expected to validate the udata
and return an error if there's unexpected content, and data from
the wrong command counts as "unexpected content", so this ends
up causing the driver's destroy call to fail.
A similar issue exists in the rereg_mr path when a new MR
is created and the old one is destroyed.
Fix this by clearing driver_udata before invoking the driver's
destroy method.
Fixes: 6e0954b11c05 ("RDMA/uverbs: Allow drivers to create a new HW object during rereg_mr")
Fixes: 0ac8903cbbe6 ("RDMA/core: Allow the ioctl layer to abort a fully created uobject")
Signed-off-by: Jacob Moroni <jmoroni@google.com>
Link: https://patch.msgid.link/20261006152908.888059-1-jmoroni@google.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Diffstat (limited to 'include/linux/platform_data')
0 files changed, 0 insertions, 0 deletions
