All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.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:03:29 -0400	[thread overview]
Message-ID: <20180427190329.GC22078@hmswarspite.think-freely.org> (raw)
In-Reply-To: <20180427181349.GA5105@localhost.localdomain>

On Fri, Apr 27, 2018 at 03:13:49PM -0300, Marcelo Ricardo Leitner wrote:
> 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.
> 
Yup, you're right.  sctp_err_lookup returns NULL if there is no transport
associated with the icmp message

Thanks
Neil

>   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
> >
> 

WARNING: multiple messages have this Message-ID (diff)
From: Neil Horman <nhorman@tuxdriver.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.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 19:03:29 +0000	[thread overview]
Message-ID: <20180427190329.GC22078@hmswarspite.think-freely.org> (raw)
In-Reply-To: <20180427181349.GA5105@localhost.localdomain>

On Fri, Apr 27, 2018 at 03:13:49PM -0300, Marcelo Ricardo Leitner wrote:
> 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.
> 
Yup, you're right.  sctp_err_lookup returns NULL if there is no transport
associated with the icmp message

Thanks
Neil

>   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
> >
> 

  reply	other threads:[~2018-04-27 19:04 UTC|newest]

Thread overview: 38+ 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 ` 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   ` 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   ` 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-26 19:58   ` Marcelo Ricardo Leitner
2018-04-27 10:50   ` Neil Horman
2018-04-27 10:50     ` Neil Horman
2018-04-27 18:13     ` Marcelo Ricardo Leitner
2018-04-27 18:13       ` Marcelo Ricardo Leitner
2018-04-27 19:03       ` Neil Horman [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   ` 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   ` 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   ` 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   ` 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   ` 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   ` 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:58   ` 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   ` 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   ` Marcelo Ricardo Leitner
2018-04-26 19:59 ` [PATCH net-next 13/13] sctp: allow unsetting sockopt MAXSEG Marcelo Ricardo Leitner
2018-04-26 19:59   ` Marcelo Ricardo Leitner
2018-04-27 10:04 ` [PATCH net-next 00/13] sctp: refactor MTU handling Xin Long
2018-04-27 10:04   ` Xin Long
2018-04-27 18:42 ` David Miller
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=20180427190329.GC22078@hmswarspite.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --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.