linux-kernel - Re: net/sunrpc/xprtrdma/frwr_ops.c:647 frwr_unmap_async() error: potentially dereferencing uninitialized 'last'.

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 23 Jun 2021 12:20:10 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>
CC:     "kbuild@...ts.01.org" <kbuild@...ts.01.org>,
        kernel test robot <lkp@...el.com>,
        "kbuild-all@...ts.01.org" <kbuild-all@...ts.01.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Trond Myklebust <trond.myklebust@...merspace.com>
Subject: Re: net/sunrpc/xprtrdma/frwr_ops.c:647 frwr_unmap_async() error:
 potentially dereferencing uninitialized 'last'.

Howdy Dan!

> On Jun 23, 2021, at 6:07 AM, Dan Carpenter <dan.carpenter@...cle.com> wrote:
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   0c18f29aae7ce3dadd26d8ee3505d07cc982df75
> commit: e10fa96d347488d1fd278e84f52ba7b25067cc71 xprtrdma: Move cqe to struct rpcrdma_mr
> config: x86_64-randconfig-m001-20210622 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@...el.com>
> Reported-by: Dan Carpenter <dan.carpenter@...cle.com>
> 
> New smatch warnings:
> net/sunrpc/xprtrdma/frwr_ops.c:647 frwr_unmap_async() error: potentially dereferencing uninitialized 'last'.
> 
> Old smatch warnings:
> net/sunrpc/xprtrdma/frwr_ops.c:546 frwr_unmap_sync() error: potentially dereferencing uninitialized 'last'.
> 
> vim +/last +647 net/sunrpc/xprtrdma/frwr_ops.c
> 
> d8099feda4833b Chuck Lever 2019-06-19  608  void frwr_unmap_async(struct rpcrdma_xprt *r_xprt, struct rpcrdma_req *req)
> d8099feda4833b Chuck Lever 2019-06-19  609  {
> d8099feda4833b Chuck Lever 2019-06-19  610  	struct ib_send_wr *first, *last, **prev;
> 5ecef9c8436695 Chuck Lever 2020-11-09  611  	struct rpcrdma_ep *ep = r_xprt->rx_ep;
> d8099feda4833b Chuck Lever 2019-06-19  612  	struct rpcrdma_frwr *frwr;
> d8099feda4833b Chuck Lever 2019-06-19  613  	struct rpcrdma_mr *mr;
> d8099feda4833b Chuck Lever 2019-06-19  614  	int rc;
> d8099feda4833b Chuck Lever 2019-06-19  615  
> d8099feda4833b Chuck Lever 2019-06-19  616  	/* Chain the LOCAL_INV Work Requests and post them with
> d8099feda4833b Chuck Lever 2019-06-19  617  	 * a single ib_post_send() call.
> d8099feda4833b Chuck Lever 2019-06-19  618  	 */
> d8099feda4833b Chuck Lever 2019-06-19  619  	frwr = NULL;
> d8099feda4833b Chuck Lever 2019-06-19  620  	prev = &first;
> 265a38d4611360 Chuck Lever 2019-08-19  621  	while ((mr = rpcrdma_mr_pop(&req->rl_registered))) {
> 
> Is it possible for the ->rl_registered list to be empty?

The one and only call site for frwr_unmap_async() in in rpcrdma_reply_handler():

1483         if (!list_empty(&req->rl_registered))
1484                 frwr_unmap_async(r_xprt, req);
1485                 /* LocalInv completion will complete the RPC */
1486         else
1487                 kref_put(&req->rl_kref, rpcrdma_reply_done);


> If not, then just ignore this email.

I seem to recall smatch catching this problem before. Is there a way
to annotate frwr_unmap_async() to calm smatch's nerves?


> d8099feda4833b Chuck Lever 2019-06-19  622  
> d8099feda4833b Chuck Lever 2019-06-19  623  		trace_xprtrdma_mr_localinv(mr);
> d8099feda4833b Chuck Lever 2019-06-19  624  		r_xprt->rx_stats.local_inv_needed++;
> d8099feda4833b Chuck Lever 2019-06-19  625  
> d8099feda4833b Chuck Lever 2019-06-19  626  		frwr = &mr->frwr;
> d8099feda4833b Chuck Lever 2019-06-19  627  		last = &frwr->fr_invwr;
> d8099feda4833b Chuck Lever 2019-06-19  628  		last->next = NULL;
> e10fa96d347488 Chuck Lever 2021-04-19  629  		last->wr_cqe = &mr->mr_cqe;
> d8099feda4833b Chuck Lever 2019-06-19  630  		last->sg_list = NULL;
> d8099feda4833b Chuck Lever 2019-06-19  631  		last->num_sge = 0;
> d8099feda4833b Chuck Lever 2019-06-19  632  		last->opcode = IB_WR_LOCAL_INV;
> d8099feda4833b Chuck Lever 2019-06-19  633  		last->send_flags = IB_SEND_SIGNALED;
> d8099feda4833b Chuck Lever 2019-06-19  634  		last->ex.invalidate_rkey = mr->mr_handle;
> d8099feda4833b Chuck Lever 2019-06-19  635  
> e10fa96d347488 Chuck Lever 2021-04-19  636  		last->wr_cqe->done = frwr_wc_localinv;
> e10fa96d347488 Chuck Lever 2021-04-19  637  
> d8099feda4833b Chuck Lever 2019-06-19  638  		*prev = last;
> d8099feda4833b Chuck Lever 2019-06-19  639  		prev = &last->next;
> d8099feda4833b Chuck Lever 2019-06-19  640  	}
> d8099feda4833b Chuck Lever 2019-06-19  641  
> d8099feda4833b Chuck Lever 2019-06-19  642  	/* Strong send queue ordering guarantees that when the
> d8099feda4833b Chuck Lever 2019-06-19  643  	 * last WR in the chain completes, all WRs in the chain
> d8099feda4833b Chuck Lever 2019-06-19  644  	 * are complete. The last completion will wake up the
> d8099feda4833b Chuck Lever 2019-06-19  645  	 * RPC waiter.
> d8099feda4833b Chuck Lever 2019-06-19  646  	 */
> e10fa96d347488 Chuck Lever 2021-04-19 @647  	last->wr_cqe->done = frwr_wc_localinv_done;
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
> 

--
Chuck Lever