| Message ID | 20211214192301.1496754-1-lee.jones@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | None | expand |
On Tue, 14 Dec 2021, Lee Jones wrote: > The cause of the resultant dump_stack() reported below is a > dereference of a freed pointer to 'struct sctp_endpoint' in > sctp_sock_dump(). > > This race condition occurs when a transport is cached into its > associated hash table followed by an endpoint/sock migration to a new > association in sctp_assoc_migrate() prior to their subsequent use in > sctp_diag_dump() which uses sctp_for_each_transport() to walk the hash > table calling into sctp_sock_dump() where the dereference occurs. > > BUG: KASAN: use-after-free in sctp_sock_dump+0xa8/0x438 [sctp_diag] > Call trace: > dump_backtrace+0x0/0x2dc > show_stack+0x20/0x2c > dump_stack+0x120/0x144 > print_address_description+0x80/0x2f4 > __kasan_report+0x174/0x194 > kasan_report+0x10/0x18 > __asan_load8+0x84/0x8c > sctp_sock_dump+0xa8/0x438 [sctp_diag] > sctp_for_each_transport+0x1e0/0x26c [sctp] > sctp_diag_dump+0x180/0x1f0 [sctp_diag] > inet_diag_dump+0x12c/0x168 > netlink_dump+0x24c/0x5b8 > __netlink_dump_start+0x274/0x2a8 > inet_diag_handler_cmd+0x224/0x274 > sock_diag_rcv_msg+0x21c/0x230 > netlink_rcv_skb+0xe0/0x1bc > sock_diag_rcv+0x34/0x48 > netlink_unicast+0x3b4/0x430 > netlink_sendmsg+0x4f0/0x574 > sock_write_iter+0x18c/0x1f0 > do_iter_readv_writev+0x230/0x2a8 > do_iter_write+0xc8/0x2b4 > vfs_writev+0xf8/0x184 > do_writev+0xb0/0x1a8 > __arm64_sys_writev+0x4c/0x5c > el0_svc_common+0x118/0x250 > el0_svc_handler+0x3c/0x9c > el0_svc+0x8/0xc > > To prevent this from happening we need to take a references to the > to-be-used/dereferenced 'struct sock' and 'struct sctp_endpoint's > until such a time when we know it can be safely released. > > When KASAN is not enabled, a similar, but slightly different NULL > pointer derefernce crash occurs later along the thread of execution in > inet_sctp_diag_fill() this time. > > Cc: Vlad Yasevich <vyasevich@gmail.com> > Cc: Neil Horman <nhorman@tuxdriver.com> > Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Jakub Kicinski <kuba@kernel.org> > Cc: lksctp developers <linux-sctp@vger.kernel.org> > Cc: "H.P. Yarroll" <piggy@acm.org> > Cc: Karl Knutson <karl@athena.chicago.il.us> > Cc: Jon Grimm <jgrimm@us.ibm.com> > Cc: Xingang Guo <xingang.guo@intel.com> > Cc: Hui Huang <hui.huang@nokia.com> > Cc: Sridhar Samudrala <sri@us.ibm.com> > Cc: Daisy Chang <daisyc@us.ibm.com> > Cc: Ryan Layer <rmlayer@us.ibm.com> > Cc: Kevin Gao <kevin.gao@intel.com> > Cc: linux-sctp@vger.kernel.org > Cc: netdev@vger.kernel.org > Signed-off-by: Lee Jones <lee.jones@linaro.org> > --- > net/sctp/diag.c | 4 ++++ > 1 file changed, 4 insertions(+) Ignore this one. For some reason 1/2 didn't send. Submitted a RESEND of the set.
diff --git a/net/sctp/diag.c b/net/sctp/diag.c index 760b367644c12..2029b240b6f24 100644 --- a/net/sctp/diag.c +++ b/net/sctp/diag.c @@ -301,6 +301,8 @@ static int sctp_sock_dump(struct sctp_transport *tsp, void *p) struct sctp_association *assoc; int err = 0; + sctp_endpoint_hold(ep); + sock_hold(sk); lock_sock(sk); list_for_each_entry(assoc, &ep->asocs, asocs) { if (cb->args[4] < cb->args[1]) @@ -341,6 +343,8 @@ static int sctp_sock_dump(struct sctp_transport *tsp, void *p) cb->args[4] = 0; release: release_sock(sk); + sock_put(sk); + sctp_endpoint_put(ep); return err; }
The cause of the resultant dump_stack() reported below is a dereference of a freed pointer to 'struct sctp_endpoint' in sctp_sock_dump(). This race condition occurs when a transport is cached into its associated hash table followed by an endpoint/sock migration to a new association in sctp_assoc_migrate() prior to their subsequent use in sctp_diag_dump() which uses sctp_for_each_transport() to walk the hash table calling into sctp_sock_dump() where the dereference occurs. BUG: KASAN: use-after-free in sctp_sock_dump+0xa8/0x438 [sctp_diag] Call trace: dump_backtrace+0x0/0x2dc show_stack+0x20/0x2c dump_stack+0x120/0x144 print_address_description+0x80/0x2f4 __kasan_report+0x174/0x194 kasan_report+0x10/0x18 __asan_load8+0x84/0x8c sctp_sock_dump+0xa8/0x438 [sctp_diag] sctp_for_each_transport+0x1e0/0x26c [sctp] sctp_diag_dump+0x180/0x1f0 [sctp_diag] inet_diag_dump+0x12c/0x168 netlink_dump+0x24c/0x5b8 __netlink_dump_start+0x274/0x2a8 inet_diag_handler_cmd+0x224/0x274 sock_diag_rcv_msg+0x21c/0x230 netlink_rcv_skb+0xe0/0x1bc sock_diag_rcv+0x34/0x48 netlink_unicast+0x3b4/0x430 netlink_sendmsg+0x4f0/0x574 sock_write_iter+0x18c/0x1f0 do_iter_readv_writev+0x230/0x2a8 do_iter_write+0xc8/0x2b4 vfs_writev+0xf8/0x184 do_writev+0xb0/0x1a8 __arm64_sys_writev+0x4c/0x5c el0_svc_common+0x118/0x250 el0_svc_handler+0x3c/0x9c el0_svc+0x8/0xc To prevent this from happening we need to take a references to the to-be-used/dereferenced 'struct sock' and 'struct sctp_endpoint's until such a time when we know it can be safely released. When KASAN is not enabled, a similar, but slightly different NULL pointer derefernce crash occurs later along the thread of execution in inet_sctp_diag_fill() this time. Cc: Vlad Yasevich <vyasevich@gmail.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: lksctp developers <linux-sctp@vger.kernel.org> Cc: "H.P. Yarroll" <piggy@acm.org> Cc: Karl Knutson <karl@athena.chicago.il.us> Cc: Jon Grimm <jgrimm@us.ibm.com> Cc: Xingang Guo <xingang.guo@intel.com> Cc: Hui Huang <hui.huang@nokia.com> Cc: Sridhar Samudrala <sri@us.ibm.com> Cc: Daisy Chang <daisyc@us.ibm.com> Cc: Ryan Layer <rmlayer@us.ibm.com> Cc: Kevin Gao <kevin.gao@intel.com> Cc: linux-sctp@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> --- net/sctp/diag.c | 4 ++++ 1 file changed, 4 insertions(+)