[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160913.114535.186471066793791952.davem@davemloft.net>
Date: Tue, 13 Sep 2016 11:45:35 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: lucien.xin@...il.com
Cc: netdev@...r.kernel.org, linux-sctp@...r.kernel.org,
marcelo.leitner@...il.com, vyasevich@...il.com,
daniel@...earbox.net
Subject: Re: [PATCHv2 net] sctp: hold the transport before using it in
sctp_hash_cmp
From: Xin Long <lucien.xin@...il.com>
Date: Sat, 10 Sep 2016 23:11:23 +0800
> Since commit 4f0087812648 ("sctp: apply rhashtable api to send/recv
> path"), sctp uses transport rhashtable with .obj_cmpfn sctp_hash_cmp,
> in which it compares the members of the transport with the rhashtable
> args to check if it's the right transport.
>
> But sctp uses the transport without holding it in sctp_hash_cmp, it can
> cause a use-after-free panic. As after it gets transport from hashtable,
> another CPU may close the sk and free the asoc. In sctp_association_free,
> it frees all the transports, meanwhile, the assoc's refcnt may be reduced
> to 0, assoc can be destroyed by sctp_association_destroy.
>
> So after that, transport->assoc is actually an unavailable memory address
> in sctp_hash_cmp. Although sctp_hash_cmp is under rcu_read_lock, it still
> can not avoid this, as assoc is not freed by RCU.
>
> This patch is to hold the transport before checking it's members with
> sctp_transport_hold, in which it checks the refcnt first, holds it if
> it's not 0.
>
> Fixes: 4f0087812648 ("sctp: apply rhashtable api to send/recv path")
> Signed-off-by: Xin Long <lucien.xin@...il.com>
Applied and queued up for -stable.
Powered by blists - more mailing lists