From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: netdev@vger.kernel.org, linux-sctp@vger.kernel.org,
Vlad Yasevich <vyasevich@gmail.com>,
Xin Long <lucien.xin@gmail.com>
Subject: Re: [PATCH net-next 03/13] sctp: remove an if() that is always true
Date: Fri, 27 Apr 2018 15:13:49 -0300 [thread overview]
Message-ID: <20180427181349.GA5105@localhost.localdomain> (raw)
In-Reply-To: <20180427105050.GA22078@hmswarspite.think-freely.org>
On Fri, Apr 27, 2018 at 06:50:50AM -0400, Neil Horman wrote:
> On Thu, Apr 26, 2018 at 04:58:52PM -0300, Marcelo Ricardo Leitner wrote:
> > As noticed by Xin Long, the if() here is always true as PMTU can never
> > be 0.
> >
> > Reported-by: Xin Long <lucien.xin@gmail.com>
> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > ---
> > net/sctp/associola.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> > index b3aa95222bd52113295cb246c503c903bdd5c353..c5ed09cfa8423b17546e3d45f6d06db03af66384 100644
> > --- a/net/sctp/associola.c
> > +++ b/net/sctp/associola.c
> > @@ -1397,10 +1397,8 @@ void sctp_assoc_sync_pmtu(struct sctp_association *asoc)
> > pmtu = t->pathmtu;
> > }
> >
> > - if (pmtu) {
> > - asoc->pathmtu = pmtu;
> > - asoc->frag_point = sctp_frag_point(asoc, pmtu);
> > - }
> > + asoc->pathmtu = pmtu;
> > + asoc->frag_point = sctp_frag_point(asoc, pmtu);
> >
> Can you double check this? Looking at it, it seems far fetched, but if someone
Sure.
> sends a crafted icmp dest unreach message to the host, pmtu_sending might be
> able to get set for an association (which may have no transports established
> yet), and if so, on the first packet send sctp_assoc_sync_pmtu can be called,
> leading to a fall through in the loop over all transports, and pmtu being zero.
> It seems like a far fetched set of circumstances, I know, but if it can happen,
> I think you might see a crash in sctp_frag_point due to an underflow of the frag
> value
If I got you right, this situation would not happen because when
handling the icmp it will check if there is a transport and ignore it
otherwise.
Marcelo
>
> Neil
>
> > pr_debug("%s: asoc:%p, pmtu:%d, frag_point:%d\n", __func__, asoc,
> > asoc->pathmtu, asoc->frag_point);
> > --
> > 2.14.3
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2018-04-27 18:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 19:58 [PATCH net-next 00/13] sctp: refactor MTU handling Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 01/13] sctp: remove old and unused SCTP_MIN_PMTU Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 02/13] sctp: move transport pathmtu calc away of sctp_assoc_add_peer Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 03/13] sctp: remove an if() that is always true Marcelo Ricardo Leitner
2018-04-27 10:50 ` Neil Horman
2018-04-27 18:13 ` Marcelo Ricardo Leitner [this message]
2018-04-27 19:03 ` Neil Horman
2018-04-26 19:58 ` [PATCH net-next 04/13] sctp: introduce sctp_assoc_set_pmtu Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 05/13] sctp: introduce sctp_mtu_payload Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 06/13] sctp: introduce sctp_assoc_update_frag_point Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 07/13] sctp: remove sctp_assoc_pending_pmtu Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 08/13] sctp: introduce sctp_dst_mtu Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 09/13] sctp: remove sctp_transport_pmtu_check Marcelo Ricardo Leitner
2018-04-26 19:58 ` [PATCH net-next 10/13] sctp: re-use sctp_transport_pmtu in sctp_transport_route Marcelo Ricardo Leitner
2018-04-26 19:59 ` [PATCH net-next 11/13] sctp: honor PMTU_DISABLED when handling icmp Marcelo Ricardo Leitner
2018-04-26 19:59 ` [PATCH net-next 12/13] sctp: consider idata chunks when setting SCTP_MAXSEG Marcelo Ricardo Leitner
2018-04-26 19:59 ` [PATCH net-next 13/13] sctp: allow unsetting sockopt MAXSEG Marcelo Ricardo Leitner
2018-04-27 10:04 ` [PATCH net-next 00/13] sctp: refactor MTU handling Xin Long
2018-04-27 18:42 ` 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=20180427181349.GA5105@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).