On Wed, 08 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 then freed prior to its subsequent use in > sctp_diag_dump() which uses sctp_for_each_transport() to walk the > (now out of date) hash table calling into sctp_sock_dump() where the > dereference occurs. > > To prevent this from happening we need to take a reference on the > to-be-used/dereferenced 'struct sctp_endpoint' 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. > > 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 This looks related (reported 3 years ago!) https://lore.kernel.org/all/20181122131344.GD31918@localhost.localdomain/ -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
