All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>,
	linux-sctp@vger.kernel.org, davem@davemloft.net,
	Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [PATCHv2 net] sctp: hold transport before accessing its asoc in sctp_hash_transport
Date: Fri, 30 Nov 2018 12:05:15 +0000	[thread overview]
Message-ID: <20181130120515.GM3601@localhost.localdomain> (raw)
In-Reply-To: <92d9c2b54a60494142909f1fbb8c187aa317ab60.1543474168.git.lucien.xin@gmail.com>

On Thu, Nov 29, 2018 at 02:49:28PM +0800, Xin Long wrote:
> In sctp_hash_transport, it dereferences a transport's asoc only under
> rcu_read_lock. Without holding the transport, its asoc could be freed
> already, which leads to a use-after-free panic.
> 
> A similar fix as Commit bab1be79a516 ("sctp: hold transport before
> accessing its asoc in sctp_transport_get_next") is needed to hold
> the transport before accessing its asoc in sctp_hash_transport.
> 
> Note that as rhlist keeps the lists to a small size, this extra
> atomic operation won't cause a noticeable latency on inserting
> a transport. Yet it's not in a datapath.
> 
> v1->v2:
>   - improve the changelog.
> 
> Fixes: cd2b70875058 ("sctp: check duplicate node before inserting a new transport")
> Reported-by: syzbot+0b05d8aa7cb185107483@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  net/sctp/input.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index ce7351c..c2c0816 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -896,11 +896,16 @@ int sctp_hash_transport(struct sctp_transport *t)
>  	list = rhltable_lookup(&sctp_transport_hashtable, &arg,
>  			       sctp_hash_params);
>  
> -	rhl_for_each_entry_rcu(transport, tmp, list, node)
> +	rhl_for_each_entry_rcu(transport, tmp, list, node) {
> +		if (!sctp_transport_hold(transport))
> +			continue;
>  		if (transport->asoc->ep = t->asoc->ep) {
> +			sctp_transport_put(transport);
>  			rcu_read_unlock();
>  			return -EEXIST;
>  		}
> +		sctp_transport_put(transport);
> +	}
>  	rcu_read_unlock();
>  
>  	err = rhltable_insert_key(&sctp_transport_hashtable, &arg,
> -- 
> 2.1.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>,
	linux-sctp@vger.kernel.org, davem@davemloft.net,
	Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [PATCHv2 net] sctp: hold transport before accessing its asoc in sctp_hash_transport
Date: Fri, 30 Nov 2018 10:05:15 -0200	[thread overview]
Message-ID: <20181130120515.GM3601@localhost.localdomain> (raw)
In-Reply-To: <92d9c2b54a60494142909f1fbb8c187aa317ab60.1543474168.git.lucien.xin@gmail.com>

On Thu, Nov 29, 2018 at 02:49:28PM +0800, Xin Long wrote:
> In sctp_hash_transport, it dereferences a transport's asoc only under
> rcu_read_lock. Without holding the transport, its asoc could be freed
> already, which leads to a use-after-free panic.
> 
> A similar fix as Commit bab1be79a516 ("sctp: hold transport before
> accessing its asoc in sctp_transport_get_next") is needed to hold
> the transport before accessing its asoc in sctp_hash_transport.
> 
> Note that as rhlist keeps the lists to a small size, this extra
> atomic operation won't cause a noticeable latency on inserting
> a transport. Yet it's not in a datapath.
> 
> v1->v2:
>   - improve the changelog.
> 
> Fixes: cd2b70875058 ("sctp: check duplicate node before inserting a new transport")
> Reported-by: syzbot+0b05d8aa7cb185107483@syzkaller.appspotmail.com
> Signed-off-by: Xin Long <lucien.xin@gmail.com>

Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>

> ---
>  net/sctp/input.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index ce7351c..c2c0816 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -896,11 +896,16 @@ int sctp_hash_transport(struct sctp_transport *t)
>  	list = rhltable_lookup(&sctp_transport_hashtable, &arg,
>  			       sctp_hash_params);
>  
> -	rhl_for_each_entry_rcu(transport, tmp, list, node)
> +	rhl_for_each_entry_rcu(transport, tmp, list, node) {
> +		if (!sctp_transport_hold(transport))
> +			continue;
>  		if (transport->asoc->ep == t->asoc->ep) {
> +			sctp_transport_put(transport);
>  			rcu_read_unlock();
>  			return -EEXIST;
>  		}
> +		sctp_transport_put(transport);
> +	}
>  	rcu_read_unlock();
>  
>  	err = rhltable_insert_key(&sctp_transport_hashtable, &arg,
> -- 
> 2.1.0
> 

  reply	other threads:[~2018-11-30 12:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29  6:44 [PATCHv2 net] sctp: hold transport before accessing its asoc in sctp_epaddr_lookup_transport Xin Long
2018-11-29  6:44 ` Xin Long
2018-11-29  6:49 ` [PATCHv2 net] sctp: hold transport before accessing its asoc in sctp_hash_transport Xin Long
2018-11-29  6:49   ` Xin Long
2018-11-30 12:05   ` Marcelo Ricardo Leitner [this message]
2018-11-30 12:05     ` Marcelo Ricardo Leitner
2018-11-30 12:34   ` Neil Horman
2018-11-30 12:34     ` Neil Horman
2018-11-29 20:51 ` [PATCHv2 net] sctp: hold transport before accessing its asoc in sctp_epaddr_lookup_transport Neil Horman
2018-11-29 20:51   ` Neil Horman
2018-11-30  5:04   ` Xin Long
2018-11-30  5:04     ` Xin Long
2018-11-30 12:32     ` Neil Horman
2018-11-30 12:32       ` Neil Horman
2018-11-30 13:33       ` Marcelo Ricardo Leitner
2018-11-30 13:33         ` Marcelo Ricardo Leitner
2018-11-30 14:05         ` Neil Horman
2018-11-30 14:05           ` Neil Horman
2018-11-30 14:18           ` Marcelo Ricardo Leitner
2018-11-30 14:18             ` Marcelo Ricardo Leitner
2018-11-30 15:01             ` Neil Horman
2018-11-30 15:01               ` Neil Horman
2018-11-30 14:15         ` Xin Long
2018-11-30 14:15           ` Xin Long
2018-11-30 14:27           ` Neil Horman
2018-11-30 14:27             ` Neil Horman
2018-11-30 14:47             ` Xin Long
2018-11-30 14:47               ` Xin Long
2018-11-30 12:04 ` Marcelo Ricardo Leitner
2018-11-30 12:04   ` Marcelo Ricardo Leitner

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=20181130120515.GM3601@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.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.