[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADvbK_c2+X1f4NiBCXU0b_9r3V-TduuUdUrt2bhBbZV8OOBz2Q@mail.gmail.com>
Date: Tue, 14 Nov 2017 20:57:17 +0800
From: Xin Long <lucien.xin@...il.com>
To: Neil Horman <nhorman@...driver.com>
Cc: network dev <netdev@...r.kernel.org>, linux-sctp@...r.kernel.org,
davem <davem@...emloft.net>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
syzkaller <syzkaller@...glegroups.com>
Subject: Re: [PATCH net] sctp: check stream reset info len before making
reconf chunk
On Tue, Nov 14, 2017 at 8:46 PM, Neil Horman <nhorman@...driver.com> wrote:
> On Mon, Nov 13, 2017 at 11:15:40PM +0800, Xin Long wrote:
>> On Mon, Nov 13, 2017 at 11:09 PM, Neil Horman <nhorman@...driver.com> wrote:
>> > On Mon, Nov 13, 2017 at 01:39:27PM +0800, Xin Long wrote:
>> >> Now when resetting stream, if both in and out flags are set, the info
>> >> len can reach:
>> >> sizeof(struct sctp_strreset_outreq) + SCTP_MAX_STREAM(65535) +
>> >> sizeof(struct sctp_strreset_inreq) + SCTP_MAX_STREAM(65535)
>> >> even without duplicated stream no, this value is far greater than the
>> >> chunk's max size.
>> >>
>> >> _sctp_make_chunk doesn't do any check for this, which would cause the
>> >> skb it allocs is huge, syzbot even reported a crash due to this.
>> >>
>> >> This patch is to check stream reset info len before making reconf
>> >> chunk and return NULL if the len exceeds chunk's capacity.
>> >>
>> >> Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk")
>> >> Reported-by: Dmitry Vyukov <dvyukov@...gle.com>
>> >> Signed-off-by: Xin Long <lucien.xin@...il.com>
>> >> ---
>> >> net/sctp/sm_make_chunk.c | 7 +++++--
>> >> net/sctp/stream.c | 8 +++++---
>> >> 2 files changed, 10 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
>> >> index 514465b..a21328a 100644
>> >> --- a/net/sctp/sm_make_chunk.c
>> >> +++ b/net/sctp/sm_make_chunk.c
>> >> @@ -3598,14 +3598,17 @@ struct sctp_chunk *sctp_make_strreset_req(
>> >> __u16 stream_len = stream_num * 2;
>> >> struct sctp_strreset_inreq inreq;
>> >> struct sctp_chunk *retval;
>> >> - __u16 outlen, inlen;
>> >> + int outlen, inlen;
>> >>
>> >> outlen = (sizeof(outreq) + stream_len) * out;
>> >> inlen = (sizeof(inreq) + stream_len) * in;
>> >>
>> >> + if (outlen + inlen > SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_chunkhdr))
>> >> + return ERR_PTR(-EINVAL);
>> >> +
>> > Why all the ERR_PTR manipulations here? Just returning NULL, like the fuction
>> > has been doing is sufficient to set ENOMEM at both call sites
>> I don't like ERR_PTR handling here either,
>> But it shouldn't be ENOMEM, should it ?
>>
>> It may confuse users, but I'm also ok to let it just return
>> ENOMEM as you wish. wdyt ?
>>
> I'm ok with ENOMEM. If someone tries to reconf the streams with huge values,
> ENOMEM makes sense to me
okay, thanks.
I will move the check to sctp_send_reset_streams() to fix
both this one and the one Marcelo mentioned.
> Neil
>
>> >
>> > Neil
>> >
>> >> retval = sctp_make_reconf(asoc, outlen + inlen);
>> >> if (!retval)
>> >> - return NULL;
>> >> + return ERR_PTR(-ENOMEM);
>> >>
>> >> if (outlen) {
>> >> outreq.param_hdr.type = SCTP_PARAM_RESET_OUT_REQUEST;
>> >> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
>> >> index fa8371f..51a25bf 100644
>> >> --- a/net/sctp/stream.c
>> >> +++ b/net/sctp/stream.c
>> >> @@ -162,8 +162,8 @@ int sctp_send_reset_streams(struct sctp_association *asoc,
>> >>
>> >> kfree(nstr_list);
>> >>
>> >> - if (!chunk) {
>> >> - retval = -ENOMEM;
>> >> + if (IS_ERR(chunk)) {
>> >> + retval = PTR_ERR(chunk);
>> >> goto out;
>> >> }
>> >>
>> >> @@ -482,8 +482,10 @@ struct sctp_chunk *sctp_process_strreset_inreq(
>> >> }
>> >>
>> >> chunk = sctp_make_strreset_req(asoc, nums, str_p, 1, 0);
>> >> - if (!chunk)
>> >> + if (IS_ERR(chunk)) {
>> >> + chunk = NULL;
>> >> goto out;
>> >> + }
>> >>
>> >> if (nums)
>> >> for (i = 0; i < nums; i++)
>> >> --
>> >> 2.1.0
>> >>
>> >>
>>
Powered by blists - more mailing lists