linux-ext4 - [PATCH] ext4: Ensure zeroout blocks have no dirty metadata

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

Message-ID: <6601abe90912100928v747671dat489aeee5dabf2c03@mail.gmail.com>
Date:	Thu, 10 Dec 2009 09:28:28 -0800
From:	Curt Wohlgemuth <curtw@...gle.com>
To:	ext4 development <linux-ext4@...r.kernel.org>
Subject: [PATCH] ext4: Ensure zeroout blocks have no dirty metadata

This fixes a bug in which new blocks returned from an extent created with
ext4_ext_zeroout() can have dirty metadata still associated with them.

	Signed-off-by: Curt Wohlgemuth <curtw@...gle.com>
---

This is for the problem I reported on 23 Nov ("Bug in extent zeroout: blocks
not marked as new").  I'm not seeing the corruption with this fix that I was
seeing without it.

diff -uprN orig/fs/ext4/extents.c new/fs/ext4/extents.c
--- orig/fs/ext4/extents.c	2009-12-09 15:09:25.000000000 -0800
+++ new/fs/ext4/extents.c	2009-12-09 15:09:37.000000000 -0800
@@ -2474,9 +2474,21 @@ static int ext4_ext_zeroout(struct inode
 		submit_bio(WRITE, bio);
 		wait_for_completion(&event);

-		if (test_bit(BIO_UPTODATE, &bio->bi_flags))
+		/* On success, we need to insure all metadata associated
+		 * with each of these blocks is unmapped. */
+		if (test_bit(BIO_UPTODATE, &bio->bi_flags)) {
+			sector_t block = ee_pblock;
+
 			ret = 0;
-		else {
+			done = 0;
+			while (done < len) {
+				unmap_underlying_metadata(inode->i_sb->s_bdev,
+							  block);
+
+				done++;
+				block++;
+			}
+		} else {
 			ret = -EIO;
 			break;
 		}
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html