From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Jakub Audykowicz <jakub.audykowicz@gmail.com>,
linux-sctp@vger.kernel.org, vyasevich@gmail.com,
davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH net] sctp: frag_point sanity check
Date: Tue, 04 Dec 2018 19:52:02 +0000 [thread overview]
Message-ID: <20181204195202.GA11247@localhost.localdomain> (raw)
In-Reply-To: <20181204193946.GC31778@hmswarspite.think-freely.org>
On Tue, Dec 04, 2018 at 02:39:46PM -0500, Neil Horman wrote:
> On Tue, Dec 04, 2018 at 08:27:41PM +0100, Jakub Audykowicz wrote:
> > If for some reason an association's fragmentation point is zero,
> > sctp_datamsg_from_user will try to endlessly try to divide a message
> > into zero-sized chunks. This eventually causes kernel panic due to
> > running out of memory.
> >
> > Although this situation is quite unlikely, it has occurred before as
> > reported. I propose to add this simple last-ditch sanity check due to
> > the severity of the potential consequences.
> >
> > Signed-off-by: Jakub Audykowicz <jakub.audykowicz@gmail.com>
> > ---
> > include/net/sctp/sctp.h | 5 +++++
> > net/sctp/chunk.c | 6 ++++++
> > net/sctp/socket.c | 3 +--
> > 3 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> > index ab9242e51d9e..2abbc15824af 100644
> > --- a/include/net/sctp/sctp.h
> > +++ b/include/net/sctp/sctp.h
> > @@ -620,4 +620,9 @@ static inline bool sctp_transport_pmtu_check(struct sctp_transport *t)
> > return false;
> > }
> >
> > +static inline __u32 sctp_min_frag_point(struct sctp_sock *sp, __u16 datasize)
> > +{
> > + return sctp_mtu_payload(sp, SCTP_DEFAULT_MINSEGMENT, datasize);
> > +}
> > +
> > #endif /* __net_sctp_h__ */
> > diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> > index ce8087846f05..d5b91bc8a377 100644
> > --- a/net/sctp/chunk.c
> > +++ b/net/sctp/chunk.c
> > @@ -191,6 +191,12 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
> > * the packet
> > */
> > max_data = asoc->frag_point;
> > + if (unlikely(!max_data)) {
> > + max_data = sctp_min_frag_point(sctp_sk(asoc->base.sk),
> > + sctp_datachk_len(&asoc->stream));
> > + pr_warn_ratelimited("%s: asoc:%p frag_point is zero, forcing max_data to default minimum (%d)",
> > + __func__, asoc, max_data);
> > + }
> >
> > /* If the the peer requested that we authenticate DATA chunks
> > * we need to account for bundling of the AUTH chunks along with
> > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > index bf618d1b41fd..b8cebd5a87e5 100644
> > --- a/net/sctp/socket.c
> > +++ b/net/sctp/socket.c
> > @@ -3324,8 +3324,7 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
> > __u16 datasize = asoc ? sctp_datachk_len(&asoc->stream) :
> > sizeof(struct sctp_data_chunk);
> >
> > - min_len = sctp_mtu_payload(sp, SCTP_DEFAULT_MINSEGMENT,
> > - datasize);
> > + min_len = sctp_min_frag_point(sp, datasize);
> > max_len = SCTP_MAX_CHUNK_LEN - datasize;
> >
> > if (val < min_len || val > max_len)
> > --
> > 2.17.1
> >
> >
> Why not just prevent the frag point from ever going below
> SCTP_DEFAULT_MINSEGMENT in the first place in sctp_assoc_update_frag_point?
> Something like:
>
> asoc->frag_point = SCTP_TRUNC4(frag) < SCTP_DEFAILT_MINSEGMENT) ? \
> SCTP_DEFAILT_MINSEGMENT : SCTP_TRUNC4(frag);
>
> Should do the trick I would think
> Neil
This is in the light of "sctp: update frag_point when
stream_interleave is set".
Because of
https://www.mail-archive.com/netdev@vger.kernel.org/msg256575.html
This wouldn't have helped because sctp_assoc_update_frag_point()
didn't get called. The issue is not that the calc issued a bad value,
but that it wasn't done.
Marcelo
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Jakub Audykowicz <jakub.audykowicz@gmail.com>,
linux-sctp@vger.kernel.org, vyasevich@gmail.com,
davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH net] sctp: frag_point sanity check
Date: Tue, 4 Dec 2018 17:52:02 -0200 [thread overview]
Message-ID: <20181204195202.GA11247@localhost.localdomain> (raw)
In-Reply-To: <20181204193946.GC31778@hmswarspite.think-freely.org>
On Tue, Dec 04, 2018 at 02:39:46PM -0500, Neil Horman wrote:
> On Tue, Dec 04, 2018 at 08:27:41PM +0100, Jakub Audykowicz wrote:
> > If for some reason an association's fragmentation point is zero,
> > sctp_datamsg_from_user will try to endlessly try to divide a message
> > into zero-sized chunks. This eventually causes kernel panic due to
> > running out of memory.
> >
> > Although this situation is quite unlikely, it has occurred before as
> > reported. I propose to add this simple last-ditch sanity check due to
> > the severity of the potential consequences.
> >
> > Signed-off-by: Jakub Audykowicz <jakub.audykowicz@gmail.com>
> > ---
> > include/net/sctp/sctp.h | 5 +++++
> > net/sctp/chunk.c | 6 ++++++
> > net/sctp/socket.c | 3 +--
> > 3 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> > index ab9242e51d9e..2abbc15824af 100644
> > --- a/include/net/sctp/sctp.h
> > +++ b/include/net/sctp/sctp.h
> > @@ -620,4 +620,9 @@ static inline bool sctp_transport_pmtu_check(struct sctp_transport *t)
> > return false;
> > }
> >
> > +static inline __u32 sctp_min_frag_point(struct sctp_sock *sp, __u16 datasize)
> > +{
> > + return sctp_mtu_payload(sp, SCTP_DEFAULT_MINSEGMENT, datasize);
> > +}
> > +
> > #endif /* __net_sctp_h__ */
> > diff --git a/net/sctp/chunk.c b/net/sctp/chunk.c
> > index ce8087846f05..d5b91bc8a377 100644
> > --- a/net/sctp/chunk.c
> > +++ b/net/sctp/chunk.c
> > @@ -191,6 +191,12 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
> > * the packet
> > */
> > max_data = asoc->frag_point;
> > + if (unlikely(!max_data)) {
> > + max_data = sctp_min_frag_point(sctp_sk(asoc->base.sk),
> > + sctp_datachk_len(&asoc->stream));
> > + pr_warn_ratelimited("%s: asoc:%p frag_point is zero, forcing max_data to default minimum (%d)",
> > + __func__, asoc, max_data);
> > + }
> >
> > /* If the the peer requested that we authenticate DATA chunks
> > * we need to account for bundling of the AUTH chunks along with
> > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > index bf618d1b41fd..b8cebd5a87e5 100644
> > --- a/net/sctp/socket.c
> > +++ b/net/sctp/socket.c
> > @@ -3324,8 +3324,7 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
> > __u16 datasize = asoc ? sctp_datachk_len(&asoc->stream) :
> > sizeof(struct sctp_data_chunk);
> >
> > - min_len = sctp_mtu_payload(sp, SCTP_DEFAULT_MINSEGMENT,
> > - datasize);
> > + min_len = sctp_min_frag_point(sp, datasize);
> > max_len = SCTP_MAX_CHUNK_LEN - datasize;
> >
> > if (val < min_len || val > max_len)
> > --
> > 2.17.1
> >
> >
> Why not just prevent the frag point from ever going below
> SCTP_DEFAULT_MINSEGMENT in the first place in sctp_assoc_update_frag_point?
> Something like:
>
> asoc->frag_point = SCTP_TRUNC4(frag) < SCTP_DEFAILT_MINSEGMENT) ? \
> SCTP_DEFAILT_MINSEGMENT : SCTP_TRUNC4(frag);
>
> Should do the trick I would think
> Neil
This is in the light of "sctp: update frag_point when
stream_interleave is set".
Because of
https://www.mail-archive.com/netdev@vger.kernel.org/msg256575.html
This wouldn't have helped because sctp_assoc_update_frag_point()
didn't get called. The issue is not that the calc issued a bad value,
but that it wasn't done.
Marcelo
next prev parent reply other threads:[~2018-12-04 19:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 19:27 [PATCH net] sctp: frag_point sanity check Jakub Audykowicz
2018-12-04 19:27 ` Jakub Audykowicz
2018-12-04 19:39 ` Neil Horman
2018-12-04 19:39 ` Neil Horman
2018-12-04 19:52 ` Marcelo Ricardo Leitner [this message]
2018-12-04 19:52 ` Marcelo Ricardo Leitner
2018-12-04 20:56 ` Neil Horman
2018-12-04 20:56 ` Neil Horman
2018-12-04 20:59 ` Marcelo Ricardo Leitner
2018-12-04 20:59 ` Marcelo Ricardo Leitner
2018-12-06 2:49 ` kbuild test robot
2018-12-06 2:49 ` kbuild test robot
2018-12-06 4:16 ` David Miller
2018-12-06 4:16 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181204195202.GA11247@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=davem@davemloft.net \
--cc=jakub.audykowicz@gmail.com \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=vyasevich@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.