Hi Leon and Jason. After discussions and analysis with our FW team, we've agreed that FW can stop HW to prevent HW UAF in most FW reset cases. But there's still one case where FW cannot intervene when FW reset is triggered by watchdog due to FW crash, because it is completely passive for FW. So we still need these patches to prevent this unlikely but still possible HW UAF case. Is this series okay to be applied? Thanks, Junxian On 2025/2/17 15:01, Junxian Huang wrote: > When mailboxes for resource(QP/CQ/SRQ) destruction fail, it's unable > to notify HW about the destruction. In this case, driver will still > free the resources, while HW may still access them, thus leading to > a UAF. > > This series introduces delay-destruction mechanism to fix such HW UAF, > including thw HW CTX and doorbells. > > Junxian Huang (2): > RDMA/hns: Change mtr member to pointer in hns QP/CQ/MR/SRQ/EQ struct > RDMA/hns: Fix HW doorbell UAF by adding delay-destruction mechanism > > wenglianfa (2): > RDMA/hns: Fix HW CTX UAF by adding delay-destruction mechanism > Revert "RDMA/hns: Do not destroy QP resources in the hw resetting > phase" > > drivers/infiniband/hw/hns/hns_roce_cq.c | 34 +++-- > drivers/infiniband/hw/hns/hns_roce_db.c | 91 ++++++++++---- > drivers/infiniband/hw/hns/hns_roce_device.h | 73 ++++++++--- > drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 97 +++++++-------- > drivers/infiniband/hw/hns/hns_roce_main.c | 13 ++ > drivers/infiniband/hw/hns/hns_roce_mr.c | 117 ++++++++++++++---- > drivers/infiniband/hw/hns/hns_roce_qp.c | 30 +++-- > drivers/infiniband/hw/hns/hns_roce_restrack.c | 4 +- > drivers/infiniband/hw/hns/hns_roce_srq.c | 45 ++++--- > 9 files changed, 348 insertions(+), 156 deletions(-) > > -- > 2.33.0 >
