From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752207AbdIIWoS (ORCPT ); Sat, 9 Sep 2017 18:44:18 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41471 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751866AbdIIWYn (ORCPT ); Sat, 9 Sep 2017 18:24:43 -0400 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, "Michael Zimmer" , "Theodore Ts'o" , "Jan Kara" Date: Sat, 09 Sep 2017 22:47:39 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 051/106] ext4: fix data corruption for mmap writes 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.2.93-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Jan Kara commit a056bdaae7a181f7dcc876cfab2f94538e508709 upstream. mpage_submit_page() can race with another process growing i_size and writing data via mmap to the written-back page. As mpage_submit_page() samples i_size too early, it may happen that ext4_bio_write_page() zeroes out too large tail of the page and thus corrupts user data. Fix the problem by sampling i_size only after the page has been write-protected in page tables by clear_page_dirty_for_io() call. Reported-by: Michael Zimmer Fixes: cb20d5188366f04d96d2e07b1240cc92170ade40 Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o [bwh: Backported to 3.2: The writeback path is very different here and it needs to read i_size long before calling clear_page_dirty_for_io(). So read it twice and skip the page if it changed.] Signed-off-by: Ben Hutchings --- fs/ext4/inode.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1344,7 +1344,6 @@ static int mpage_da_submit_io(struct mpa int ret = 0, err, nr_pages, i; struct inode *inode = mpd->inode; struct address_space *mapping = inode->i_mapping; - loff_t size = i_size_read(inode); unsigned int len, block_start; struct buffer_head *bh, *page_bufs = NULL; int journal_data = ext4_should_journal_data(inode); @@ -1370,6 +1369,7 @@ static int mpage_da_submit_io(struct mpa for (i = 0; i < nr_pages; i++) { int commit_write = 0, skip_page = 0; struct page *page = pvec.pages[i]; + loff_t size = i_size_read(inode); index = page->index; if (index > end) @@ -1443,11 +1443,31 @@ static int mpage_da_submit_io(struct mpa if (skip_page) goto skip_page; + clear_page_dirty_for_io(page); + /* + * We have to be very careful here! Nothing protects + * writeback path against i_size changes and the page + * can be writeably mapped into page tables. So an + * application can be growing i_size and writing data + * through mmap while writeback runs. + * clear_page_dirty_for_io() write-protects our page in + * page tables and the page cannot get written to again + * until we release page lock. So only after + * clear_page_dirty_for_io() we are safe to sample + * i_size for ext4_bio_write_page() to zero-out tail of + * the written page. We rely on the barrier provided by + * TestClearPageDirty in clear_page_dirty_for_io() to + * make sure i_size is really sampled only after page + * tables are updated. + */ + if (size != i_size_read(inode)) { + set_page_dirty(page); + goto skip_page; + } + if (commit_write) /* mark the buffer_heads as dirty & uptodate */ block_commit_write(page, 0, len); - - clear_page_dirty_for_io(page); /* * Delalloc doesn't support data journalling, * but eventually maybe we'll lift this