Received: by 10.223.185.116 with SMTP id b49csp823852wrg; Sat, 10 Feb 2018 21:14:50 -0800 (PST) X-Google-Smtp-Source: AH8x226CVZ+hiijG/oBqv1n6GOCnCgqnHQlkpO9kiyoI5sgxZRGUrzv5iirNH89VCDaQzl3mq5oJ X-Received: by 10.98.232.24 with SMTP id c24mr7743392pfi.227.1518326090385; Sat, 10 Feb 2018 21:14:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518326090; cv=none; d=google.com; s=arc-20160816; b=g+aiFgmy/z3hhbBfKFb1hml3bYZuQWIwV5zOWaG4UrVAvLKsJuU2DIlBefdwJSOXcs WlyqAqmwtYDJriCf9M/dhqD/bXMoOh55KVjAi++rBdKLPoWNrnJhdnZUaAy7pgrFsO5X SL9T0mElBJ2e6oO+gF+CmpCPYA+Ui3t6TydmmzUqyfFI2sf0NSvcSZjYTAcdSvIsU0b/ dmanMZU2IbhOps4ihqKxmS9fFGN59UgqTOR76kMhBNWSleZBBheUiLWHjcV17vilHe4p +xuS9qO0RA9KCrHFvq7+f3a+L6bYVpHkWdOwqKavIiO+8icQrlKQqmV6lG1/MlG6KO4X Sf5w== 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 :arc-authentication-results; bh=w8ShemzT2ulHYa1MXBOzleI4h3c+NmYh1QYbRXbUl64=; b=q+iOJTs2B6W/C4W8GCHr4h9dur61NmaeFOuyf0Qdp6fRk9UElg92o/c/XWpHFWrFt6 YEaAjlWZPA/mt2KaCVZRDg57XLD7LtMnLeHmgkrR839BfURHF1gakXi9NiQN311YQoPR KsW9E0L4W2LeX/QBe0sGQucCwp6XgzkvwJ3m//Nwt1Wk2OYxcISwpg28FDkcaGvUJkep Al/fFERWqvSBL5dcKMR2zhbmk0tUTFH/vOMyoTo9GZkEof/6vi5bXsNo65xCGOq//COi vlEnKxWSNuOouYIQABv5Jsd+7yJgwM+IamjIMlKfZAicpKoJAfD4oRXrK1912gKcNm87 YFPA== 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 s4si3569812pgq.658.2018.02.10.21.14.37; Sat, 10 Feb 2018 21:14:50 -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 S1753594AbeBKFMY (ORCPT + 99 others); Sun, 11 Feb 2018 00:12:24 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41381 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752602AbeBKEdl (ORCPT ); Sat, 10 Feb 2018 23:33:41 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ekjKd-0002hA-Qa; Sun, 11 Feb 2018 04:33:39 +0000 Received: from ben by deadeye with local (Exim 4.90) (envelope-from ) id 1ekjKY-0004VS-BQ; Sun, 11 Feb 2018 04:33:34 +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, "Al Viro" , "Ian Kent" Date: Sun, 11 Feb 2018 04:20:06 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 50/79] autofs4: catatonic_mode vs. notify_daemon race In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 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.2.99-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro commit 8753333266be67ff3a984ac1f6566d31c260bee4 upstream. we need to hold ->wq_mutex while we are forming the packet to send, lest we have autofs4_catatonic_mode() setting wq->name.name to NULL just as autofs4_notify_daemon() decides to memcpy() from it... We do have check for catatonic mode immediately after that (under ->wq_mutex, as it ought to be) and packet won't be actually sent, but it'll be too late for us if we oops on that memcpy() from NULL... Fix is obvious - just extend the area covered by ->wq_mutex over that switch and check whether it's catatonic *before* doing anything else. Acked-by: Ian Kent Signed-off-by: Al Viro Signed-off-by: Ben Hutchings --- fs/autofs4/waitq.c | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) --- a/fs/autofs4/waitq.c +++ b/fs/autofs4/waitq.c @@ -110,6 +110,13 @@ static void autofs4_notify_daemon(struct pkt.hdr.proto_version = sbi->version; pkt.hdr.type = type; + mutex_lock(&sbi->wq_mutex); + + /* Check if we have become catatonic */ + if (sbi->catatonic) { + mutex_unlock(&sbi->wq_mutex); + return; + } switch (type) { /* Kernel protocol v4 missing and expire packets */ case autofs_ptype_missing: @@ -163,22 +170,18 @@ static void autofs4_notify_daemon(struct } default: printk("autofs4_notify_daemon: bad type %d!\n", type); + mutex_unlock(&sbi->wq_mutex); return; } - /* Check if we have become catatonic */ - mutex_lock(&sbi->wq_mutex); - if (!sbi->catatonic) { - pipe = sbi->pipe; - get_file(pipe); - } + pipe = sbi->pipe; + get_file(pipe); + mutex_unlock(&sbi->wq_mutex); - if (pipe) { - if (autofs4_write(pipe, &pkt, pktsz)) - autofs4_catatonic_mode(sbi); - fput(pipe); - } + if (autofs4_write(pipe, &pkt, pktsz)) + autofs4_catatonic_mode(sbi); + fput(pipe); } static int autofs4_getpath(struct autofs_sb_info *sbi,