On Fri, Jan 28, 2022 at 01:16:36PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 24, 2022 at 03:25:02PM +0300, Dan Carpenter wrote:
> > Call c4iw_put_wr_wait() if c4iw_wait_for_reply() fails. This
> > code uses kobject so the worst impact from this bug is a DoS.
> >
> > Fixes: 2015f26cfade ("iw_cxgb4: add referencing to wait objects")
> > Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> > ---
> > >From static analysis. Not tested.
> >
> > drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 17 ++++++++++++-----
> > 1 file changed, 12 insertions(+), 5 deletions(-)
>
> Are you sure?
>
> Looking at the caller alloc_srq_queue() it calls down to
> c4iw_ref_send_wait() then immediately exits on failure
>
> The only caller c4iw_create_srq()
>
> ret = alloc_srq_queue(srq, ucontext ? &ucontext->uctx :
> &rhp->rdev.uctx, srq->wr_waitp);
> if (ret)
> goto err_free_skb;
>
> And then
>
> err_free_skb:
> kfree_skb(srq->destroy_skb);
> err_free_srq_idx:
> c4iw_free_srq_idx(&rhp->rdev, srq->idx);
> err_free_wr_wait:
> c4iw_put_wr_wait(srq->wr_waitp);
>
> So we just double put the thing with this patch
>
> I have no idea how this logic is supposed to work, and clearly
> something is buggy in here, but I can't say this is right..
Yeah. My patch isn't right. That refcount from my patch is supposed to
be decremented in _c4iw_wake_up(). That function gets called when the
firmware responds in fw6_msg(). So if we cleanup everything and the
firmware sends a delayed response the it leads to a use after free.
Say the firmware never responds, then sure, that leads to a resource
leak. But it's better to have a small memory leak than a use after free.
regards,
dan carpenter
