Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2236851imm; Thu, 7 Jun 2018 07:30:50 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIwM7XKo7ODYjr6rlslaApYPIjCgdjwH8QgVjDj5+H36fIY4yR3cnmyebXehVrOk8EwSydt X-Received: by 2002:a17:902:26a:: with SMTP id 97-v6mr2304459plc.367.1528381849952; Thu, 07 Jun 2018 07:30:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528381849; cv=none; d=google.com; s=arc-20160816; b=N/8MqXQGz3O/sWj0UFCjqvx12vqlM3/NYkNRtR6ioNCw2UNtvcCrzkjdHuWviVSelq I8ZmSTSQ0AZ2elmwtW3AoYzalDMZE+Qv10L1U517HmqZIvS7/yOx/QslFoBp/cFSE00C HLhJPiC9K+lKf1Tqby1vK9jldCtbC4O9at6Kh+YUAMNaWg325tTHyCH0pMo+U9Su4XCf 5vp+jtNxXdV1v5hj3UQRvATdzbLQHBvk/Sc8SCLx+o/YhYHnydT99FX1WlR0Y+LQC/iJ X4umzSpaPiYFVNw/a/A5/cKXLeqcg57NtmCyx5D7CBO5woF+RvKORcKRZi3qNeZWxRJI DXZg== 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=iqmalRuWAGttD0uI0lt4hZF76h317yJrqZ5U1Mmnjzs=; b=rOjXI8ZHYgR4N1hWWirBxjzJ7YXHH30z0n7L6SfvNpWL1gp4zFdUu7xc2VZo0bqnnh 6h2LCdV8d/XhilQrmXfFa1aa9TEW0V+vfHbqE0VNuMHxc6YnxAVhVt+ZZTSbcL1sj79X n6S9p0fz7bZycCxQvt73Cx4lU6/MEtCqrmJ8grPBWXKTOPsK4r7wT1JJRtGoI6WMGBt1 hX//N9kZGcVCL0Oiq9jNqDYoH8v0hMoK8G9RoceIyn8AhRymlJpl6wGU4WWpGqVNftQ3 VIauBufm41Q0aBPHRZxL+Rv1w4/yLOUv0ODuCwEZy1U2uTMc/o1t6KvrUjM3hjvr3WiM I7jg== 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 e72-v6si10149692pfd.352.2018.06.07.07.30.35; Thu, 07 Jun 2018 07:30:49 -0700 (PDT) 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 S933726AbeFGO33 (ORCPT + 99 others); Thu, 7 Jun 2018 10:29:29 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40222 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933697AbeFGO30 (ORCPT ); Thu, 7 Jun 2018 10:29:26 -0400 Received: from [148.252.241.226] (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 1fQvbY-0005hO-RF; Thu, 07 Jun 2018 15:09:32 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvb9-00036V-88; Thu, 07 Jun 2018 15:09:07 +0100 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, "Shaohua Li" , stable@decadent.org.uk, "NeilBrown" , "Yufen Yu" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 272/410] md raid10: fix NULL deference in handle_write_completed() In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 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.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Yufen Yu commit 01a69cab01c184d3786af09e9339311123d63d22 upstream. In the case of 'recover', an r10bio with R10BIO_WriteError & R10BIO_IsRecover will be progressed by handle_write_completed(). This function traverses all r10bio->devs[copies]. If devs[m].repl_bio != NULL, it thinks conf->mirrors[dev].replacement is also not NULL. However, this is not always true. When there is an rdev of raid10 has replacement, then each r10bio ->devs[m].repl_bio != NULL in conf->r10buf_pool. However, in 'recover', even if corresponded replacement is NULL, it doesn't clear r10bio ->devs[m].repl_bio, resulting in replacement NULL deference. This bug was introduced when replacement support for raid10 was added in Linux 3.3. As NeilBrown suggested: Elsewhere the determination of "is this device part of the resync/recovery" is made by resting bio->bi_end_io. If this is end_sync_write, then we tried to write here. If it is NULL, then we didn't try to write. Fixes: 9ad1aefc8ae8 ("md/raid10: Handle replacement devices during resync.") Cc: stable (V3.3+) Suggested-by: NeilBrown Signed-off-by: Yufen Yu Signed-off-by: Shaohua Li Signed-off-by: Ben Hutchings --- drivers/md/raid10.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -2746,7 +2746,8 @@ static void handle_write_completed(struc for (m = 0; m < conf->copies; m++) { int dev = r10_bio->devs[m].devnum; rdev = conf->mirrors[dev].rdev; - if (r10_bio->devs[m].bio == NULL) + if (r10_bio->devs[m].bio == NULL || + r10_bio->devs[m].bio->bi_end_io == NULL) continue; if (test_bit(BIO_UPTODATE, &r10_bio->devs[m].bio->bi_flags)) { @@ -2762,7 +2763,8 @@ static void handle_write_completed(struc md_error(conf->mddev, rdev); } rdev = conf->mirrors[dev].replacement; - if (r10_bio->devs[m].repl_bio == NULL) + if (r10_bio->devs[m].repl_bio == NULL || + r10_bio->devs[m].repl_bio->bi_end_io == NULL) continue; if (test_bit(BIO_UPTODATE, &r10_bio->devs[m].repl_bio->bi_flags)) {