linux-kernel - Re: [PATCH v2] drbd: Fix kernel_sendmsg() usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20161109234127.GI19539@ZenIV.linux.org.uk>
Date:   Wed, 9 Nov 2016 23:41:28 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Lars Ellenberg <lars.ellenberg@...bit.com>
Cc:     Jens Axboe <axboe@...nel.dk>, Richard Weinberger <richard@....at>,
        wolfgang.glas@...g.at, christoph.lechleitner@...g.at,
        philipp.reisner@...bit.com, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org, drbd-dev@...ts.linbit.com
Subject: Re: [PATCH v2] drbd: Fix kernel_sendmsg() usage - potential NULL
 deref

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.