diff options
| author | David S. Miller <[email protected]> | 2013-04-07 20:42:40 +0000 |
|---|---|---|
| committer | David S. Miller <[email protected]> | 2013-04-07 20:42:40 +0000 |
| commit | f89e8a6432409c6cbd5c2b6bb90ea694fd558de3 (patch) | |
| tree | 01aaa7cb29147cba0fcc1202a03bbf1af598be62 /net/unix/af_unix.c | |
| parent | ipv6/tcp: Stop processing ICMPv6 redirect messages (diff) | |
| parent | VSOCK: Fix missing msg_namelen update in vsock_stream_recvmsg() (diff) | |
| download | kernel-f89e8a6432409c6cbd5c2b6bb90ea694fd558de3.tar.gz kernel-f89e8a6432409c6cbd5c2b6bb90ea694fd558de3.zip | |
Merge branch 'infoleaks'
Mathias Krause says:
====================
a few more info leak fixes in the recvmsg path. The error pattern here
is the protocol specific recvmsg function is missing the msg_namelen
assignment -- either completely or in early exit paths that do not
result in errors in __sys_recvmsg()/sys_recvfrom() and, in turn, make
them call move_addr_to_user(), leaking the then still uninitialized
sockaddr_storage stack variable to userland.
My audit was initiated by a rather coarse fix of the leak that can be
found in the grsecurity patch, putting a penalty on protocols complying
to the rules of recvmsg. So credits for finding the leak in the recvmsg
path in __sys_recvmsg() should go to Brad!
The buggy protocols/subsystems are rather obscure anyway. As a missing
assignment of msg_namelen coupled with a missing filling of msg_name
would only result in garbage -- the leak -- in case userland would care
about that information, i.e. would provide a msg_name pointer. But
obviously current userland does not.
While auditing the code for the above pattern I found a few more
'uninitialized members' kind of leaks related to the msg_name filling.
Those are fixed in this series, too.
I have to admit, I failed to test all of the patches due to missing
hardware, e.g. iucv depends on S390 -- hardware I've no access to :/
====================
Signed-off-by: David S. Miller <[email protected]>
Diffstat (limited to 'net/unix/af_unix.c')
0 files changed, 0 insertions, 0 deletions
