Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3336255imu; Sun, 11 Nov 2018 12:39:19 -0800 (PST) X-Google-Smtp-Source: AJdET5dNdwfLd32+HMiORYxsh71OVcp6YQe8FtEhavGjVuh2BbCbxQxPU3FNILYdcNs+cO57DYJG X-Received: by 2002:a63:101d:: with SMTP id f29mr15211705pgl.38.1541968759839; Sun, 11 Nov 2018 12:39:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541968759; cv=none; d=google.com; s=arc-20160816; b=HPDrVkTOAPi71dg2OWPBNR2NVt5gGgEF9Hn5ANJSzT6x0/dA64dZeS/IyxVH7vii7A 8GHUe//6gzbpNuA+gjMB/fQHMsCuckrU6cLJeaaJJFJZsYvibXKEp1hGFIHTWj/+5HTh /wpkV2D3e/Yz32GyNwgdNYEldeGxh6U5N3sDKDeht3O5SYZJDkkLDFditgzGAPy7HH1x DJ7P1SpNaFRTPBY/pspgRv3chLtWWuID/aEALilBHC3WXqmTM+trztsmMUNwpgz43Jg9 sVLn+w/cr+0KzG1xYTrz+Z/Ph80MJQWjDohknTBibAYqaLEz+kmRm2j1or2QxKWbgrhk Wa+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=/ldrUJBeauZVnw3DVK+xEYeTHWymK74VmirrWByvqZw=; b=e+WDoD2l65vS5lyCagOGzZmk53Bkvud0wnrWzQP9VvYRS4ltlqZ41bWn2hc5Yj5fgM oqpf6TmBPsKvDyilcbI6t9zIrm/cdvOJ7HSuTmP5LGhEGsH7O37T8rpOdaA//yHn+yLT q0oVYggvqsliS8P615YKMV6YhXQQZQ9StByW4qNThq5/bjaH2C4mqoioqVLF76V8mEBS bX+QP2VwajPpSRtHaE/wUWHiF4gLlXciBtoMHp7q82bvf89RIeW7wFkDRgMNvkReGGvU 0kFJx5LzkVcjJrfou3w56G+y+GkY1W845Bm6K6oBAu2+4eZVHZFXmw0ObhnkXuDHk8d9 hSJQ== 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 l137-v6si18623628pfd.260.2018.11.11.12.39.04; Sun, 11 Nov 2018 12:39:19 -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 S1730301AbeKLG1s (ORCPT + 99 others); Mon, 12 Nov 2018 01:27:48 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49622 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730029AbeKLFsJ (ORCPT ); Mon, 12 Nov 2018 00:48:09 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvsW-0000oM-46; Sun, 11 Nov 2018 19:58:40 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsT-0001bN-9N; Sun, 11 Nov 2018 19:58:37 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "David S. Miller" , "Vitaly Kuznetsov" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 171/366] xen-netfront: avoid crashing on resume after a failure in talk_to_netback() In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Vitaly Kuznetsov commit d86b5672b1adb98b4cdd6fbf0224bbfb03db6e2e upstream. Unavoidable crashes in netfront_resume() and netback_changed() after a previous fail in talk_to_netback() (e.g. when we fail to read MAC from xenstore) were discovered. The failure path in talk_to_netback() does unregister/free for netdev but we don't reset drvdata and we try accessing it after resume. Fix the bug by removing the whole xen device completely with device_unregister(), this guarantees we won't have any calls into netfront after a failure. Signed-off-by: Vitaly Kuznetsov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/xen-netfront.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1980,8 +1980,7 @@ abort_transaction_no_dev_fatal: xennet_disconnect_backend(info); xennet_destroy_queues(info); out: - unregister_netdev(info->netdev); - xennet_free_netdev(info->netdev); + device_unregister(&dev->dev); return err; }