linux-kernel - [PATCH 3.10 012/139] leak in O

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1509571159-4405-13-git-send-email-w@1wt.eu>
Date:   Wed,  1 Nov 2017 22:17:12 +0100
From:   Willy Tarreau <w@....eu>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        linux@...ck-us.net
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Al Viro <viro@...iv.linux.org.uk>, Willy Tarreau <w@....eu>
Subject: [PATCH 3.10 012/139] leak in O_DIRECT readv past the EOF

From: Al Viro <viro@...IV.linux.org.uk>

In all versions from 2.5.62 to 3.15, on each iteration through the loop
by iovec array in do_blockdev_direct_IO() we used to do this:
                sdio.head = 0;
                sdio.tail = 0;
...
                retval = do_direct_IO(dio, &sdio, &map_bh);

                if (retval) {
                        dio_cleanup(dio, &sdio);
                        break;
                }

with another dio_cleanup() done after the loop, catching the situation when
retval had been 0.  Consider the situation when e.g. the 3rd iovec in 4-iovec
array passed to readv() has crossed the EOF.  do_direct_IO() returns 0 and
buggers off *without* exhausting the page array.  The loop proceeds to the
next iovec without calling dio_cleanup() and resets sdio.head and sdio.tail.
That reset of sdio.{head,tail} has prevented the eventual dio_cleanup() from
seeing anything and the page reference end up leaking.

Commit 7b2c99d15559 (new helper: iov_iter_get_pages()) in 3.16 had eliminated
the loop by iovec array, along with sdio.head and sdio.tail resets.  Backporting
that is too much work - the minimal fix is simply to make sure that the only case
when do_direct_IO() buggers off early without returning non-zero will not skip
dio_cleanup().

The fix applies to all versions from 2.5.62 to 3.15.

Reported-and-tested-by: Venki Pallipadi <venki@...esity.com>
Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
Signed-off-by: Willy Tarreau <w@....eu>
---
 fs/direct-io.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/direct-io.c b/fs/direct-io.c
index 7ab90f5..e17d919 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -933,6 +933,7 @@ do_holes:
 						i_size_aligned >> blkbits) {
 					/* We hit eof */
 					page_cache_release(page);
+					dio_cleanup(dio, sdio);
 					goto out;
 				}
 				zero_user(page, block_in_page << blkbits,
-- 
2.8.0.rc2.1.gbe9624a