This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun Jun 16 02:26:49 2024 >From mailfetcher Mon Dec 6 20:21:11 2021 Envelope-to: lkml@grols.ch Delivery-date: Mon, 06 Dec 2021 20:21:10 +0100 Received: from stout.grols.ch [195.201.141.146] by 72459556e3a9 with IMAP (fetchmail-6.3.26) for (single-drop); Mon, 06 Dec 2021 20:21:11 +0100 (CET) Received: from vger.kernel.org ([23.128.96.18]) by stout.grols.ch with esmtp (Exim 4.92) (envelope-from ) id 1muJXy-000722-6q for lkml@grols.ch; Mon, 06 Dec 2021 20:21:10 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348393AbhLFTYh (ORCPT ); Mon, 6 Dec 2021 14:24:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241452AbhLFTYg (ORCPT ); Mon, 6 Dec 2021 14: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B987C061354 for ; Mon, 6 Dec 2021 11:21:07 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id i12so8972527wmq.4 for ; Mon, 06 Dec 2021 11:21:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=17dMvWQJWFrU7HYHq+6U8LXq9UKpalF6hcq4itO X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=17dMvWQJWF X-Gm-Message-State: AOAM53176HFUObUD5gyuNMIu2Pu+kyAlxTd3YLs2+Au7UAuvH03vFnPm DzvQ1by06mwoPzy9C2HaaE7ofg== X-Google-Smtp-Source: ABdhPJzUqF3sHYHJXA6kO6W6NE7EZuMoA50/Oi+NTHo45Z52I0AKGQT/OjjeCzWHU4THVRVJVo3PqQ== X-Received: by 2002:a7b:c256:: with SMTP id b22mr634701wmj.176.1638818466059; Mon, 06 Dec 2021 11:21:06 -0800 (PST) Received: from google.com ([2.31.167.18]) by smtp.gmail.com with ESMTPSA id g16sm311850wmq.20.2021.12.06.11.21.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Dec 2021 11:21:05 -0800 (PST) Date: Mon, 6 Dec 2021 19:21:03 +0000 From: Lee Jones To: Marcelo Ricardo Leitner Cc: Xin Long , syzbot+9276d76e83e3bcde6c99@syzkaller.appspotmail.com, davem , LKML , linux-sctp@vger.kernel.org, network dev , Ne Subject: Re: KASAN: use-after-free Read in __lock_sock Message-Id: References: <000000000000b98a67057ad7158a@google.com> <20181122131344.GD31918@localhost.localdomain> <20181122143743.GE31918@loc Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20181122143743.GE31918@localhost.localdomain> Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org Received-SPF: pass client-ip=23.128.96.18; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org X-Spam-Score: -1.5 X-Spam-Score-Bar: - X-Spam-Action: no action X-Spam-Report: Action: no action Symbol: RCVD_VIA_SMTP_AUTH(0.00) Symbol: TO_DN_SOME(0.00) Symbol: R_SPF_ALLOW(-0.20) Symbol: DKIM_TRACE(0.00) Symbol: DMARC_POLICY_ALLOW(-0.50) Symbol: RCPT_COUNT_SEVEN(0.00) Symbol: MAILLIST(-0.10) Symbol: FREEMAIL_TO(0.00) Symbol: RCV Networking Gurus, On Thu, 22 Nov 2018, Marcelo Ricardo Leitner wrote: > On Thu, Nov 22, 2018 at 10:44:16PM +0900, Xin Long wrote: > > On Thu, Nov 22, 2018 at 10:13 PM Marcelo Ricardo Leitner > > wrote: > > > > > > On Mon, Nov 19, 2018 at 05:57:33PM +0900, Xin Long wrote: > > > > On Sat, Nov 17, 2018 at 4:18 PM syzbot > > > > wrote: > > > > > > > > > > Hello, > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > HEAD commit: ccda4af0f4b9 Linux 4.20-rc2 > > > > > git tree: upstream > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=156cd53= 3400000 > > > > > kernel config: https://syzkaller.appspot.com/x/.config?xJ0a89f12= ca9b0f5 > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=E2=80=997= 6d76e83e3bcde6c99 > > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > > > > > > > IMPORTANT: if you fix the bug, please add the following tag to th= e commit: > > > > > Reported-by: syzbot+9276d76e83e3bcde6c99@syzkaller.appspotmail.com > > > > > > > > > > netlink: 5 bytes leftover after parsing attributes in process > > > > > `syz-executor5'. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 > > > > > kernel/locking/lockdep.c:3218 > > > > > Read of size 8 at addr ffff8881d26d60e0 by task syz-executor1/137= 25 > > > > > > > > > > CPU: 0 PID: 13725 Comm: syz-executor1 Not tainted 4.20.0-rc2+ #333 > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine= , BIOS > > > > > Google 01/01/2011 > > > > > Call Trace: > > > > > __dump_stack lib/dump_stack.c:77 [inline] > > > > > dump_stack+0x244/0x39d lib/dump_stack.c:113 > > > > > print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 > > > > > kasan_report_error mm/kasan/report.c:354 [inline] > > > > > kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 > > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > > > > > __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 > > > > > lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 > > > > > __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] > > > > > _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 > > > > > spin_lock_bh include/linux/spinlock.h:334 [inline] > > > > > __lock_sock+0x203/0x350 net/core/sock.c:2253 > > > > > lock_sock_nested+0xfe/0x120 net/core/sock.c:2774 > > > > > lock_sock include/net/sock.h:1492 [inline] > > > > > sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 > > > > > > > > static int sctp_sock_dump(struct sctp_transport *tsp, void *p) > > > > { > > > > struct sctp_endpoint *ep =3D tsp->asoc->ep; > > > > struct sctp_comm_param *commp =3D p; > > > > struct sock *sk =3D ep->base.sk; <--- [1] > > > > ... > > > > int err =3D 0; > > > > > > > > lock_sock(sk); <--- [2] > > > > > > > > Between [1] and [2], an asoc peeloff may happen, still thinking > > > > how to avoid this. > > > > > > This race cannot happen more than once for an asoc, so something > > > like this may be doable: > > > > > > struct sctp_comm_param *commp =3D p; > > > struct sctp_endpoint *ep; > > > struct sock *sk; > > > ... > > > int err =3D 0; > > > > > > again: > > > ep =3D tsp->asoc->ep; > > > sk =3D ep->base.sk; <---[3] > > > lock_sock(sk); <--- [2] > > if peel-off happens between [3] and [2], and sk is freed > > somewhere, it will panic on [2] when trying to get the > > sk->lock, no? >=20 > Not sure what protects it, but this construct is also used in BH processi= ng at > sctp_rcv(): > ... > bh_lock_sock(sk); [4] >=20 > if (sk !=3D rcvr->sk) { > /* Our cached sk is different from the rcvr->sk. This is > * because migrate()/accept() may have moved the associat= ion > * to a new socket and released all the sockets. So now = we > * are holding a lock on the old socket while the user may > * be doing something with the new socket. Switch our ve= iw > * of the current sk. > */ > bh_unlock_sock(sk); > sk =3D rcvr->sk; > bh_lock_sock(sk); > } > ... >=20 > If it is not safe, then we have an issue there too. > And by [4] that copy on sk is pretty old already. >=20 > >=20 > > > if (sk !=3D tsp->asoc->ep->base.sk) { > > > /* Asoc was peeloff'd */ > > > unlock_sock(sk); > > > goto again; > > > } > > > > > > Similarly to what we did on cea0cc80a677 ("sctp: use the right sk > > > after waking up from wait_buf sleep"). I'm currently debugging something similar (the same perhaps) on an older Stable kernel. However the same Repro which was found and authored for a production level mobile phone, doesn't seem to trigger on an x86_64 qemu instance running Mainline. That's not to say that Mainline isn't still suffering with this issue though. It probably has more to do with the specificity of the Repro which was designed specifically to trigger on the target device. Does anyone know if this particular issue was ever patched? --=20 Lee Jones [=E6=9D=8E=E7=90=BC=E6=96=AF] Senior Technical Lead - Developer Services Linaro.org =E2=94=82 Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog