linux-kernel - RE: [PATCH] RDMA/siw: Fix potential siw_mem refcnt leak in nr_add

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <OFF7AE12D1.38AFBC66-ON0025854B.004E30DB-0025854B.004E73A2@notes.na.collabserv.com>
Date:   Wed, 15 Apr 2020 14:16:54 +0000
From:   "Bernard Metzler" <BMT@...ich.ibm.com>
To:     "Jason Gunthorpe" <jgg@...pe.ca>
Cc:     "Xiyu Yang" <xiyuyang19@...an.edu.cn>,
        "Doug Ledford" <dledford@...hat.com>, linux-rdma@...r.kernel.org,
        linux-kernel@...r.kernel.org, yuanxzhang@...an.edu.cn,
        kjlu@....edu, "Xin Tan" <tanxin.ctf@...il.com>
Subject: RE: [PATCH] RDMA/siw: Fix potential siw_mem refcnt leak in nr_add_node

-----"Jason Gunthorpe" <jgg@...pe.ca> wrote: -----

>To: "Xiyu Yang" <xiyuyang19@...an.edu.cn>
>From: "Jason Gunthorpe" <jgg@...pe.ca>
>Date: 04/15/2020 04:09PM
>Cc: "Bernard Metzler" <bmt@...ich.ibm.com>, "Doug Ledford"
><dledford@...hat.com>, linux-rdma@...r.kernel.org,
>linux-kernel@...r.kernel.org, yuanxzhang@...an.edu.cn, kjlu@....edu,
>"Xin Tan" <tanxin.ctf@...il.com>
>Subject: [EXTERNAL] Re: [PATCH] RDMA/siw: Fix potential siw_mem
>refcnt leak in nr_add_node
>
>On Wed, Apr 15, 2020 at 04:39:08PM +0800, Xiyu Yang wrote:
>> siw_fastreg_mr() invokes siw_mem_id2obj(), which returns a local
>> reference of the siw_mem object to "mem" with increased refcnt.
>> When siw_fastreg_mr() returns, "mem" becomes invalid, so the
>refcount
>> should be decreased to keep refcount balanced.
>> 
>> The issue happens in one error path of siw_fastreg_mr(). When
>"base_mr"
>> equals to NULL but "mem" is not NULL, the function forgets to
>decrease
>> the refcnt increased by siw_mem_id2obj() and causes a refcnt leak.
>> 
>> Fix this issue by calling siw_mem_put() on this error path when mem
>is
>> not NULL.
>> 
>> Signed-off-by: Xiyu Yang <xiyuyang19@...an.edu.cn>
>> Signed-off-by: Xin Tan <tanxin.ctf@...il.com>
>>  drivers/infiniband/sw/siw/siw_qp_tx.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/infiniband/sw/siw/siw_qp_tx.c
>b/drivers/infiniband/sw/siw/siw_qp_tx.c
>> index ae92c8080967..86044a44b83b 100644
>> +++ b/drivers/infiniband/sw/siw/siw_qp_tx.c
>> @@ -926,6 +926,8 @@ static int siw_fastreg_mr(struct ib_pd *pd,
>struct siw_sqe *sqe)
>>  	siw_dbg_pd(pd, "STag 0x%08x\n", sqe->rkey);
>>  
>>  	if (unlikely(!mem || !base_mr)) {
>> +		if (mem)
>> +			siw_mem_put(mem);
>>  		pr_warn("siw: fastreg: STag 0x%08x unknown\n", sqe->rkey);
>>  		return -EINVAL;
>>  	}
>
>I think I prefer this version, which is what I'll use if nobody has
>concerns:
>
>diff --git a/drivers/infiniband/sw/siw/siw_qp_tx.c
>b/drivers/infiniband/sw/siw/siw_qp_tx.c
>index ae92c8080967c5..0580bbf535ceb7 100644
>--- a/drivers/infiniband/sw/siw/siw_qp_tx.c
>+++ b/drivers/infiniband/sw/siw/siw_qp_tx.c
>@@ -920,20 +920,28 @@ static int siw_fastreg_mr(struct ib_pd *pd,
>struct siw_sqe *sqe)
> {
> 	struct ib_mr *base_mr = (struct ib_mr *)(uintptr_t)sqe->base_mr;
> 	struct siw_device *sdev = to_siw_dev(pd->device);
>-	struct siw_mem *mem = siw_mem_id2obj(sdev, sqe->rkey  >> 8);
>+	struct siw_mem *mem;
> 	int rv = 0;
> 
> 	siw_dbg_pd(pd, "STag 0x%08x\n", sqe->rkey);
> 
>-	if (unlikely(!mem || !base_mr)) {
>+	if (unlikely(!base_mr)) {
> 		pr_warn("siw: fastreg: STag 0x%08x unknown\n", sqe->rkey);
> 		return -EINVAL;
> 	}
>+
> 	if (unlikely(base_mr->rkey >> 8 != sqe->rkey  >> 8)) {
> 		pr_warn("siw: fastreg: STag 0x%08x: bad MR\n", sqe->rkey);
>+		return -EINVAL;
>+	}
>+
>+	mem = siw_mem_id2obj(sdev, sqe->rkey  >> 8);
>+	if (unlikely(!mem)) {
>+		pr_warn("siw: fastreg: STag 0x%08x unknown\n", sqe->rkey);
> 		rv = -EINVAL;
> 		goto out;
> 	}
>+

Fine with me in principle, but we would have to return
directly here as well - since we do not have a valid mem
to be put back.

Thanks
Bernard.