The clean up is handled by the caller, rpcrdma_buffer_create(), so this
call to rpcrdma_sendctxs_destroy() leads to a double free.
Fixes: ae72950abf99 ("xprtrdma: Add data structure to manage RDMA Send arguments")
Signed-off-by: Dan Carpenter <[email protected]>
---
net/sunrpc/xprtrdma/verbs.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
index 3dde05892c8e..4994e75945b8 100644
--- a/net/sunrpc/xprtrdma/verbs.c
+++ b/net/sunrpc/xprtrdma/verbs.c
@@ -845,17 +845,13 @@ static int rpcrdma_sendctxs_create(struct rpcrdma_xprt *r_xprt)
for (i = 0; i <= buf->rb_sc_last; i++) {
sc = rpcrdma_sendctx_create(&r_xprt->rx_ia);
if (!sc)
- goto out_destroy;
+ return -ENOMEM;
sc->sc_xprt = r_xprt;
buf->rb_sc_ctxs[i] = sc;
}
return 0;
-
-out_destroy:
- rpcrdma_sendctxs_destroy(buf);
- return -ENOMEM;
}
/* The sendctx queue is not guaranteed to have a size that is a
--
2.17.1
> On Jan 5, 2019, at 8:06 AM, Dan Carpenter <[email protected]> wrote:
>
> The clean up is handled by the caller, rpcrdma_buffer_create(), so this
> call to rpcrdma_sendctxs_destroy() leads to a double free.
True. This fix is adequate, but I'm wondering if rpcrdma_sendctxs_destroy
should be made more careful about being called twice. Hm.
Reviewed-by: Chuck Lever <[email protected]>
> Fixes: ae72950abf99 ("xprtrdma: Add data structure to manage RDMA Send arguments")
> Signed-off-by: Dan Carpenter <[email protected]>
> ---
> net/sunrpc/xprtrdma/verbs.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
> index 3dde05892c8e..4994e75945b8 100644
> --- a/net/sunrpc/xprtrdma/verbs.c
> +++ b/net/sunrpc/xprtrdma/verbs.c
> @@ -845,17 +845,13 @@ static int rpcrdma_sendctxs_create(struct rpcrdma_xprt *r_xprt)
> for (i = 0; i <= buf->rb_sc_last; i++) {
> sc = rpcrdma_sendctx_create(&r_xprt->rx_ia);
> if (!sc)
> - goto out_destroy;
> + return -ENOMEM;
>
> sc->sc_xprt = r_xprt;
> buf->rb_sc_ctxs[i] = sc;
> }
>
> return 0;
> -
> -out_destroy:
> - rpcrdma_sendctxs_destroy(buf);
> - return -ENOMEM;
> }
>
> /* The sendctx queue is not guaranteed to have a size that is a
> --
> 2.17.1
>
--
Chuck Lever
On Sat, Jan 05, 2019 at 11:24:45AM -0500, Chuck Lever wrote:
>
> > On Jan 5, 2019, at 8:06 AM, Dan Carpenter <[email protected]> wrote:
> >
> > The clean up is handled by the caller, rpcrdma_buffer_create(), so this
> > call to rpcrdma_sendctxs_destroy() leads to a double free.
>
> True. This fix is adequate, but I'm wondering if rpcrdma_sendctxs_destroy
> should be made more careful about being called twice. Hm.
>
> Reviewed-by: Chuck Lever <[email protected]>
I'm assuming Trond or Anna will pick this up.--b.
>
>
> > Fixes: ae72950abf99 ("xprtrdma: Add data structure to manage RDMA Send arguments")
> > Signed-off-by: Dan Carpenter <[email protected]>
> > ---
> > net/sunrpc/xprtrdma/verbs.c | 6 +-----
> > 1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
> > index 3dde05892c8e..4994e75945b8 100644
> > --- a/net/sunrpc/xprtrdma/verbs.c
> > +++ b/net/sunrpc/xprtrdma/verbs.c
> > @@ -845,17 +845,13 @@ static int rpcrdma_sendctxs_create(struct rpcrdma_xprt *r_xprt)
> > for (i = 0; i <= buf->rb_sc_last; i++) {
> > sc = rpcrdma_sendctx_create(&r_xprt->rx_ia);
> > if (!sc)
> > - goto out_destroy;
> > + return -ENOMEM;
> >
> > sc->sc_xprt = r_xprt;
> > buf->rb_sc_ctxs[i] = sc;
> > }
> >
> > return 0;
> > -
> > -out_destroy:
> > - rpcrdma_sendctxs_destroy(buf);
> > - return -ENOMEM;
> > }
> >
> > /* The sendctx queue is not guaranteed to have a size that is a
> > --
> > 2.17.1
> >
>
> --
> Chuck Lever
>
>
On Sat, Jan 05, 2019 at 11:24:45AM -0500, Chuck Lever wrote:
>
> > On Jan 5, 2019, at 8:06 AM, Dan Carpenter <[email protected]> wrote:
> >
> > The clean up is handled by the caller, rpcrdma_buffer_create(), so this
> > call to rpcrdma_sendctxs_destroy() leads to a double free.
>
> True. This fix is adequate, but I'm wondering if rpcrdma_sendctxs_destroy
> should be made more careful about being called twice. Hm.
>
I actually wrote the patch like that originally, but then this way made
for an easier patch description so I re-wrote it. Let me send the other
patch and you can apply that or both if you want.
regards,
dan carpenter
There was a double free in the error handling here recently. It was
a bit subtle which function was supposed to call rpcrdma_sendctxs_destroy()
so it was called in both.
This patch makes it so we can call rpcrdma_sendctxs_destroy() twice
in a row without crashing.
Signed-off-by: Dan Carpenter <[email protected]>
---
net/sunrpc/xprtrdma/verbs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
index 7749a2bf6887..d05f4885548d 100644
--- a/net/sunrpc/xprtrdma/verbs.c
+++ b/net/sunrpc/xprtrdma/verbs.c
@@ -802,9 +802,12 @@ static void rpcrdma_sendctxs_destroy(struct rpcrdma_buffer *buf)
{
unsigned long i;
+ if (!buf->rb_sc_ctxs)
+ return;
for (i = 0; i <= buf->rb_sc_last; i++)
kfree(buf->rb_sc_ctxs[i]);
kfree(buf->rb_sc_ctxs);
+ buf->rb_sc_ctxs = NULL;
}
static struct rpcrdma_sendctx *rpcrdma_sendctx_create(struct rpcrdma_ia *ia)
--
2.17.1
> On Jan 7, 2019, at 2:08 PM, Dan Carpenter <[email protected]> wrote:
>
> There was a double free in the error handling here recently. It was
> a bit subtle which function was supposed to call rpcrdma_sendctxs_destroy()
> so it was called in both.
>
> This patch makes it so we can call rpcrdma_sendctxs_destroy() twice
> in a row without crashing.
Belt-and-braces. I think the other patch "must" be applied, and this
one "should" be applied.
Reviewed-by: Chuck Lever <[email protected]>
> Signed-off-by: Dan Carpenter <[email protected]>
> ---
> net/sunrpc/xprtrdma/verbs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
> index 7749a2bf6887..d05f4885548d 100644
> --- a/net/sunrpc/xprtrdma/verbs.c
> +++ b/net/sunrpc/xprtrdma/verbs.c
> @@ -802,9 +802,12 @@ static void rpcrdma_sendctxs_destroy(struct rpcrdma_buffer *buf)
> {
> unsigned long i;
>
> + if (!buf->rb_sc_ctxs)
> + return;
> for (i = 0; i <= buf->rb_sc_last; i++)
> kfree(buf->rb_sc_ctxs[i]);
> kfree(buf->rb_sc_ctxs);
> + buf->rb_sc_ctxs = NULL;
> }
>
> static struct rpcrdma_sendctx *rpcrdma_sendctx_create(struct rpcrdma_ia *ia)
> --
> 2.17.1
>
--
Chuck Lever
On Mon, 2019-01-07 at 12:22 -0500, Bruce Fields wrote:
> On Sat, Jan 05, 2019 at 11:24:45AM -0500, Chuck Lever wrote:
> > > On Jan 5, 2019, at 8:06 AM, Dan Carpenter <[email protected]>
> > > wrote:
> > >
> > > The clean up is handled by the caller, rpcrdma_buffer_create(), so this
> > > call to rpcrdma_sendctxs_destroy() leads to a double free.
> >
> > True. This fix is adequate, but I'm wondering if rpcrdma_sendctxs_destroy
> > should be made more careful about being called twice. Hm.
> >
> > Reviewed-by: Chuck Lever <[email protected]>
>
> I'm assuming Trond or Anna will pick this up.--b.
Yeah, I'll take this one and 1/2 for a 5.0-rc. I might save the additional
cleanup patch Dan sent for 5.1
Anna
>
> >
> > > Fixes: ae72950abf99 ("xprtrdma: Add data structure to manage RDMA Send
> > > arguments")
> > > Signed-off-by: Dan Carpenter <[email protected]>
> > > ---
> > > net/sunrpc/xprtrdma/verbs.c | 6 +-----
> > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > >
> > > diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
> > > index 3dde05892c8e..4994e75945b8 100644
> > > --- a/net/sunrpc/xprtrdma/verbs.c
> > > +++ b/net/sunrpc/xprtrdma/verbs.c
> > > @@ -845,17 +845,13 @@ static int rpcrdma_sendctxs_create(struct
> > > rpcrdma_xprt *r_xprt)
> > > for (i = 0; i <= buf->rb_sc_last; i++) {
> > > sc = rpcrdma_sendctx_create(&r_xprt->rx_ia);
> > > if (!sc)
> > > - goto out_destroy;
> > > + return -ENOMEM;
> > >
> > > sc->sc_xprt = r_xprt;
> > > buf->rb_sc_ctxs[i] = sc;
> > > }
> > >
> > > return 0;
> > > -
> > > -out_destroy:
> > > - rpcrdma_sendctxs_destroy(buf);
> > > - return -ENOMEM;
> > > }
> > >
> > > /* The sendctx queue is not guaranteed to have a size that is a
> > > --
> > > 2.17.1
> > >
> >
> > --
> > Chuck Lever
> >
> >