linux-kernel - writev data loss bug in (at least) 2.6.31 and 2.6.32pre8 x86-64

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]

Date:	Mon, 30 Nov 2009 15:55:01 -0500
From:	James Y Knight <foom@...m.net>
To:	linux-kernel@...r.kernel.org
Subject: writev data loss bug in (at least) 2.6.31 and 2.6.32pre8 x86-64

This test case fails in 2.6.23-2.6.25, because of the bug fixed in 864f24395c72b6a6c48d13f409f986dc71a5cf4a, and now again in at least 2.6.31 and 2.6.32pre8 because of a *different* bug. This test *does not* fail 2.6.26. I have not tested anything between 2.6.26 and 2.6.31.

The bug in 2.6.31 is definitely not the same bug as 2.6.23's. This time, the zero'd area of the file doesn't show up immediately upon writing the file. Instead, the kernel waits to mangle the file until it has to flush the buffer to disk. *THEN* it zeros out parts of the file.

So, after writing out the new file with writev, and checking the md5sum (which is correct), this test case asks the kernel to flush the cache for that file, and then checks the md5sum again. ONLY THEN is the file corrupted. That is, I won't hesitate to say *incredibly evil* behavior: it took me quite some time to figure out WTH was going wrong with my program before determining it was a kernel bug.

This test case is distilled from an actual application which doesn't even intentionally use writev: it just uses C++'s ofstream class to write data to a file. Unfortunately, that class smart and uses writev under the covers. Unfortunately, I guess nobody ever tests linux writev behavior, since it's broken _so_much_of_the_time_. I really am quite astounded to see such a bad track record for such a fundamental core system call....

My /tmp is an ext3 filesystem, in case that matters.

Here is the output I get from running the program on a broken kernel:
Compiling test program
Making original file /tmp/writevtest.yzafRmFCOR/test.in
..checking original file's md5sum.
Running test to copy to /tmp/writevtest.yzafRmFCOR/test.out
..checking new file's md5sum.
Attempting to drop the page cache for this file...
..checking new file's md5sum again.
MD5SUM MISMATCH(/tmp/writevtest.yzafRmFCOR/test.out):
  wanted 2fdd6851b32ae931637d4845c037b550
  got    67e5e2d6d4435e8095335d86a3d3e993

(please CC responses to me, I'm not subscribed to this list).

Thanks,
James

Download attachment "run-writev-test.sh" of type "application/octet-stream" (974 bytes)

Download attachment "writev-test.c" of type "application/octet-stream" (1854 bytes)