Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754733AbcKIXlh (ORCPT ); Wed, 9 Nov 2016 18:41:37 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:42328 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752287AbcKIXlg (ORCPT ); Wed, 9 Nov 2016 18:41:36 -0500 Date: Wed, 9 Nov 2016 23:41:28 +0000 From: Al Viro To: Lars Ellenberg Cc: Jens Axboe , Richard Weinberger , wolfgang.glas@iteg.at, christoph.lechleitner@iteg.at, philipp.reisner@linbit.com, stable@vger.kernel.org, linux-kernel@vger.kernel.org, drbd-dev@lists.linbit.com Subject: Re: [PATCH v2] drbd: Fix kernel_sendmsg() usage - potential NULL deref Message-ID: <20161109234127.GI19539@ZenIV.linux.org.uk> References: <60514f9b-6f1c-8b7e-429a-490cdaae14d8@kernel.dk> <1478728378-22289-1-git-send-email-lars.ellenberg@linbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1478728378-22289-1-git-send-email-lars.ellenberg@linbit.com> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1252 Lines: 23 On Wed, Nov 09, 2016 at 10:52:58PM +0100, Lars Ellenberg wrote: > This should go into 4.9, > and into all stable branches since and including v4.0, > which is the first to contain the exposing change. > > It is correct for all stable branches older than that as well > (which contain the DRBD driver; which is 2.6.33 and up). > > It requires a small "conflict" resolution for v4.4 and earlier, with v4.5 > we dropped the comment block immediately preceding the kernel_sendmsg(). ACK. I'll rebase commit 7a4992299554 ([drbd] use sock_sendmsg()) on top of that as soon as it hits the mainline. For conspiracy theorists out there (hi, Brad) - that commit (killing the modifications of iovec and reinitializing msg->iov_iter; just set it once and let sendmsg() update it in normal fashion) had been sitting around since late 2014. It happened to fix the bug in question, without a single line refering to that in commit message. Reason: I had completely missed the problem; intent of that loop had been obvious and replacement had obviously done what was intended there. What I had failed to spot was that the code in there did *not* match that intent. Replacement does. And unlike the minimal fix (either version) it doesn't belong in -stable.