linux-kernel - Re: [RFC] writev() semantics with invalid iovec in the middle

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]

Date:   Fri, 16 Sep 2016 14:25:14 +0100
From:   One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     Mike Marshall <hubcap@...ibond.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC] writev() semantics with invalid iovec in the middle

> Unfortunately, some of LTP writev tests end up checking that writev() does
> behave that way - they feed it a three-element iovec with shorter-than-page
> segments, the second of which is all invalid.  And they check that the
> entire first segment had been written.

1003.1 says

"Each iovec entry specifies the base address and length of an area in
memory from which data should be written. The writev() function shall
always write a complete area before proceeding to the next."

and I imagine that is what LTP is attempting to test.

The moment you pass an invalid address you are in the land of undefined
behaviour, so I would read the standard as actually trying to deal with
the behaviour in defined situations (eg out of disk space mid writev()).

Alan