linux-kernel - 2.6.19-rc4-mm1: writev() _functional

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:	Sun, 12 Nov 2006 17:30:24 -0500
From:	Nick Orlov <bugfixer@...t.ru>
To:	Andrew Morton <akpm@...l.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: 2.6.19-rc4-mm1: writev() _functional_ regression

Andrew,

Somewhere in between 2.6.18-mm3 and 2.6.19-rc4-mm1 writev() got screwed.
It does not accept zero-length segments anymore.

Bad thing that it is extremely easy to trigger (even w/o explicit writev calls).
For example the following innocent program will fail with 2.6.19-rc4-mm1:

======================
#include <string.h>
#include <fstream>

int main()
{
  char buf[1024];
  memset(buf, 'A', sizeof(buf));
  std::ofstream ofs("test");
  //ofs << 1 << '\n';
  ofs.write(buf, sizeof(buf));
  return 0;
}
======================


Here is the corresponding part if strace:

======================
open("test", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
writev(3, [{NULL, 0}, {"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1024}], 2) = -1 EFAULT (Bad address)
close(3)                                = 0
======================


With 2.6.18-mm3 it works

======================
open("test", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
writev(3, [{NULL, 0}, {"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1024}], 2) = 1024
close(3)                                = 0
======================


It works with 2.6.19-rc4-mm1 _if_ zero-length segments are eliminated
(by uncommenting ofs << 1 << '\n'):

======================
open("test", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
writev(3, [{"1\n", 2}, {"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 1024}], 2) = 1026
close(3)                                = 0
======================


Given that _all_ applications using C++ streams are potentially affected
I think it's better to preserve the previous behavior even if it is
something from "undefined behavior world" (or a plain bug).

The bug is quite dangerous (I was really close to wipe out my mp3 collection).

Please let me know if you want me to try any patches.

Thank you,
	Nick Orlov.
-- 
With best wishes,
	Nick Orlov.

-
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/