Re: [BUG] RDMA/rxe: memory leak in rxe_qp_from_attr

[Peiyang He]

On 2026/7/31 02:07, yanjun.zhu wrote:
> On 7/30/26 1:40 AM, Peiyang He wrote:
> 
> Thanks for the detailed analysis.
> 
> From the RDMA usage perspective, concurrent MODIFY_QP operations on the same QP are not normally expected in real workloads. Typically, after a QP is created and transitioned to the required state, applications use it for communication. If a QP attribute or resource needs to be modified, it is usually done by the owner thread/process in a serialized manner rather than by multiple threads concurrently modifying the same QP.
> 
> However, since the kernel interface does allow such a scenario, especially under malicious input or fuzzing environments, the driver should still handle this case safely.
> 
> For the fix, I agree that the resource replacement path needs proper serialization. My preference would be to reuse an existing QP lock if there is one suitable for protecting QP attribute modifications, rather than introducing a new `rd_atomic_mutex` specifically for this field. Adding a new lock may increase locking complexity and could introduce additional lock ordering concerns.

Thanks for your suggestion. I looked into the RXE code and it seems there is no suitable existing lock we can reuse to serialize QP attribute modifications.
There is a spinlock_t state_lock in struct rxe_qp. However, since the IB_QP_MAX_DEST_RD_ATOMIC path in rxe_qp_from_attr() will eventually call kzalloc(GFP_KERNEL), using this spinlock may not be the best practice.> 
> It may also be worth checking whether other QP attribute modification paths have similar concurrency assumptions. If the QP modify path is generally expected to be serialized, protecting the broader QP modification operation with an existing lock might provide a more consistent solution.

Yes, rxe_prepare_res() and find_resource() also use qp->resp.resources. They should be serialized with rxe_qp_from_attr() as well.

Thanks,
Peiyang