netdev - Re: [PATCH net] sctp: fix memleak on err handling of stream initialization

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]

Message-ID: <20191217123329.GH4444@localhost.localdomain>
Date:   Tue, 17 Dec 2019 09:33:29 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Neil Horman <nhorman@...driver.com>
Cc:     netdev@...r.kernel.org, Xin Long <lucien.xin@...il.com>,
        Kent Overstreet <kent.overstreet@...il.com>,
        linux-sctp@...r.kernel.org
Subject: Re: [PATCH net] sctp: fix memleak on err handling of stream
 initialization

On Tue, Dec 17, 2019 at 06:55:13AM -0500, Neil Horman wrote:
> On Mon, Dec 16, 2019 at 10:01:16PM -0300, Marcelo Ricardo Leitner wrote:
> > syzbot reported a memory leak when an allocation fails within
> > genradix_prealloc() for output streams. That's because
> > genradix_prealloc() leaves initialized members initialized when the
> > issue happens and SCTP stack will abort the current initialization but
> > without cleaning up such members.
> > 
> > The fix here is to always call genradix_free() when genradix_prealloc()
> > fails, for output and also input streams, as it suffers from the same
> > issue.
> > 
> > Reported-by: syzbot+772d9e36c490b18d51d1@...kaller.appspotmail.com
> > Fixes: 2075e50caf5e ("sctp: convert to genradix")
> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
> > ---
> >  net/sctp/stream.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > index df60b5ef24cbf5c6f628ab8ed88a6faaaa422b6d..e0b01bf912b3f3cdbc3f713bcfa50868e4802929 100644
> > --- a/net/sctp/stream.c
> > +++ b/net/sctp/stream.c
> > @@ -84,8 +84,10 @@ static int sctp_stream_alloc_out(struct sctp_stream *stream, __u16 outcnt,
> >  		return 0;
> >  
> >  	ret = genradix_prealloc(&stream->out, outcnt, gfp);
> > -	if (ret)
> > +	if (ret) {
> > +		genradix_free(&stream->out);
> >  		return ret;
> > +	}
> >  
> >  	stream->outcnt = outcnt;
> >  	return 0;
> > @@ -100,8 +102,10 @@ static int sctp_stream_alloc_in(struct sctp_stream *stream, __u16 incnt,
> >  		return 0;
> >  
> >  	ret = genradix_prealloc(&stream->in, incnt, gfp);
> > -	if (ret)
> > +	if (ret) {
> > +		genradix_free(&stream->in);
> >  		return ret;
> > +	}
> >  
> >  	stream->incnt = incnt;
> >  	return 0;
> > -- 
> > 2.23.0
> > 
> > 
> As mentioned in the other thread, shouldn't genradix_prealloc clean this up
> internal to its function.  It seems odd having to free memory allocated on
> error.

Depends on how fatal you're considering that it is.  With the current
version of genradix_prealloc() there could be a place that attempted
to pre-allocate it, it failed, and then resumed later on. SCTP can't
do that, because right after this prealloc it will write to each
and every element in there, but someone could.

  Marcelo