Received: by 10.223.185.116 with SMTP id b49csp439818wrg; Tue, 20 Feb 2018 01:54:09 -0800 (PST) X-Google-Smtp-Source: AH8x2270l4Tdf0YUyDf2y8q9NT8cD/wqvzu7lb7Fl09IRWthklbe1iQDkDRHWWkdB6Ru7dPRN/Qa X-Received: by 10.101.96.212 with SMTP id r20mr1599823pgv.139.1519120448951; Tue, 20 Feb 2018 01:54:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519120448; cv=none; d=google.com; s=arc-20160816; b=O5gKuzwu3IiOx4gxGNRtPN4nzG+unkEB0bizyMsT4LTGIk9Hdom0L03eOqu4mndcOv JmMk9iUa8TI1tfRDv/nydkkrn1Y6qxuSfitbhyIv5O+/qCyyaHK9HDnXTNahc2n/9zu/ DmMYf5aMIhdqDGW7ijorv2ih8NVSvugdlSzH6Egc7Yx1V3fkfoH397Qls1pcIz3CwpLg y/a10yI7hiriAnRUZ1jHVhQilR2F9Sd283aLXn1GQsgGM8RCtf71zyabAAJ8WeWL1tTR d0K/JGEe6PVPQU/J5CivskgkFbmzNrC+lROklZwP0n0HfeZZQ5pZrFziOItI/RkLCWpW 8LHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=0PelpJtVQPt7sfYjk8bF7CvQc5I5K1WQmU5nXfxX6Ms=; b=Wpo9St3qZOg4dqHe1nDk/gADoIu8KCXryu0zGxIoyqOZSHFfWm9MMg1K9jGvh2ispj kYgI8SFzUGOUSxsbMtJDK1A96bWktgUAZBrHFI2BnF9O4tnBWhAPKMrif9o8ryzFwP9P 8oUR7ZhjicnKUM7v5R3Bra1xlB8XErP5izkG249NxEowZzQyQJvlFaQ1eVqO5D+brWFi n1R1xr0lTfnLO6AZxjNWT4Hn6qdqeKUTvosG8aYs0iXYnTC+8lz3AM/2/irSjzWIspkA NQsWsQMxL+llQ4KurDradXGNQGWF5+ek1TN9VDO7JCgTcfN61O1OBo4qRpZi/3Pp0YQ4 XEmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b62si6233162pfa.29.2018.02.20.01.53.53; Tue, 20 Feb 2018 01:54:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751260AbeBTJxO (ORCPT + 99 others); Tue, 20 Feb 2018 04:53:14 -0500 Received: from a.mx.secunet.com ([62.96.220.36]:36604 "EHLO a.mx.secunet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750735AbeBTJxL (ORCPT ); Tue, 20 Feb 2018 04:53:11 -0500 Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 005A52007F; Tue, 20 Feb 2018 10:53:10 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCZrqIXW5F54; Tue, 20 Feb 2018 10:53:08 +0100 (CET) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 8D1E220063; Tue, 20 Feb 2018 10:53:08 +0100 (CET) Received: from gauss2.secunet.de (10.182.7.193) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server id 14.3.382.0; Tue, 20 Feb 2018 10:53:07 +0100 Received: by gauss2.secunet.de (Postfix, from userid 1000) id DC08831824FD; Tue, 20 Feb 2018 10:53:07 +0100 (CET) Date: Tue, 20 Feb 2018 10:53:07 +0100 From: Steffen Klassert To: Dmitry Vyukov CC: syzbot , , Greg Kroah-Hartman , "H. Peter Anvin" , Kate Stewart , LKML , Ingo Molnar , , Philippe Ombredanne , , Thomas Gleixner , "the arch/x86 maintainers" , Herbert Xu , David Miller , netdev Subject: Re: INFO: rcu detected stall in xfrm_confirm_neigh Message-ID: <20180220095307.lh4m6m43354i7cal@gauss3.secunet.de> References: <001a1141ba9ea381f70565057687@google.com> <20180219072243.vk7ow4gdpqhz5gbp@gauss3.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) X-G-Data-MailSecurity-for-Exchange-State: 0 X-G-Data-MailSecurity-for-Exchange-Error: 0 X-G-Data-MailSecurity-for-Exchange-Sender: 23 X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93 X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 X-G-Data-MailSecurity-for-Exchange-Guid: C0D6CA9D-99E1-4956-818A-5E094A0E0A00 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 19, 2018 at 11:05:38AM +0100, Dmitry Vyukov wrote: > On Mon, Feb 19, 2018 at 8:22 AM, Steffen Klassert > wrote: > >> > wrote: > >> >> Hello, > >> >> > >> >> syzbot hit the following crash on net-next commit > >> >> 9515a2e082f91457db0ecff4b65371d0fb5d9aad (Thu Jan 25 03:37:38 2018 +0000) > >> >> net/ipv4: Allow send to local broadcast from a socket bound to a VRF > >> >> > >> >> So far this crash happened 6 times on net-next. > >> >> Unfortunately, I don't have any reproducer for this crash yet. > >> >> Raw console output is attached. > >> >> compiler: gcc (GCC) 7.1.1 20170620 > >> >> .config is attached. > >> > > >> > > >> > +xfrm maintainers > >> > >> Here is a C repro: > >> https://gist.githubusercontent.com/dvyukov/92c67ba9afaaa960bcfbdc6ef549ac10/raw/786f9221c1d707c7f4a15effcb1d5997dd4f8638/gistfile1.txt > > > > Seems like syzbot does not know about this reproducer. > > > > I've send a patch to test and got this as the reply: > > > > This crash does not have a reproducer. I cannot test it. > > Yes, it does not know about the reproducer. I've extracted it > manually, these hangs are sometimes hard to reproduce. For syzbot this > bug does not have a reproducer. > Have you tried to run the reproducer? For me it reproduced the bug > quite reliably. I've tried the reproducer, it does not trigger with my kernel config and with your config my machine does not boot. So it was just easy to ask syzbot for a test. Anyway, Florian Westphal did a test and confirmed that the patch fixes the issue. I've just applied the fix below to the ipsec tree. Subject: [PATCH] xfrm: Fix infinite loop in xfrm_get_dst_nexthop with transport mode. On transport mode we forget to fetch the child dst_entry before we continue the while loop, this leads to an infinite loop. Fix this by fetching the child dst_entry before we continue the while loop. Fixes: 0f6c480f23f4 ("xfrm: Move dst->path into struct xfrm_dst") Reported-by: syzbot+7d03c810e50aaedef98a@syzkaller.appspotmail.com Tested-by: Florian Westphal Signed-off-by: Steffen Klassert --- net/xfrm/xfrm_policy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c index 150d46633ce6..625b3fca5704 100644 --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -2732,14 +2732,14 @@ static const void *xfrm_get_dst_nexthop(const struct dst_entry *dst, while (dst->xfrm) { const struct xfrm_state *xfrm = dst->xfrm; + dst = xfrm_dst_child(dst); + if (xfrm->props.mode == XFRM_MODE_TRANSPORT) continue; if (xfrm->type->flags & XFRM_TYPE_REMOTE_COADDR) daddr = xfrm->coaddr; else if (!(xfrm->type->flags & XFRM_TYPE_LOCAL_COADDR)) daddr = &xfrm->id.daddr; - - dst = xfrm_dst_child(dst); } return daddr; } -- 2.14.1