linux-kernel - [PATCH] ext3: wait on all pending commits in ext3_sync

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: <20081103184426.GA31894@ajones-laptop.nbttech.com>
Date:	Mon, 3 Nov 2008 10:44:26 -0800
From:	Arthur Jones <ajones@...erbed.com>
To:	Eric Sandeen <sandeen@...hat.com>
CC:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	"sct@...hat.com" <sct@...hat.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [PATCH] ext3: wait on all pending commits in ext3_sync_fs

Hi Eric,   This patch fixes the problem for me, and
seems to put the buffers on the dirty list at the
place where they are put on the list during the working
case.  Despite having rooted around in the innards of
ext3 for the last few days, I cannot say that I have
any sense of whether this patch will cause problems
elsewhere or even if this is the best place to
intercede.

I post the complete patch not because I think it
should be committed as is, but rather to try
to explain the logic that brought it about.  At the
very least, this should be reviewed by the experts
here to make sure there is no collateral damage.

Arthur

-------------------
In ext3_sync_fs, we only wait for a commit to
finish if we started it, but there may be one
already in progress which will not be synced.

In the case of a data=ordered umount with pending long
symlinks which are delayed due to a long list
of other I/O on the backing block device, this
causes the buffer associated with the long symlinks
to not be moved to the inode dirty list in the second
phase of fsync_super.  Then, before they can be dirtied
again, kjournald exits, seeing the UMOUNT flag and the
dirty pages are never written to the backing block device,
causing long symlink corruption and exposing new or
previously freed block data to userspace.

This can be reproduced with a script created
by Eric Sandeen <sandeen@...hat.com>:

	#!/bin/bash

	umount /mnt/test2
	mount /dev/sdb4 /mnt/test2
	rm -f /mnt/test2/*
	dd if=/dev/zero of=/mnt/test2/bigfile bs=1M count=512
	touch
	/mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
	ln -s
	/mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
	/mnt/test2/link
	umount /mnt/test2
	mount /dev/sdb4 /mnt/test2
	ls /mnt/test2/
	umount /mnt/test2

To ensure all commits are synced, we flush
all journal commits now when sync_fs'ing ext3.

Signed-off-by: Arthur Jones <ajones@...erbed.com>
---
 fs/ext3/super.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 18eaa78..053659a 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2392,7 +2392,13 @@ static int ext3_sync_fs(struct super_block *sb, int wait)
 	if (journal_start_commit(EXT3_SB(sb)->s_journal, &target)) {
 		if (wait)
 			log_wait_commit(EXT3_SB(sb)->s_journal, target);
-	}
+	} else if (wait)
+		/*
+		 * We may have a commit in progress, clear it out
+		 * before we go on...
+		 */
+		ext3_force_commit(sb);
+
 	return 0;
 }

-- 
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/