Merge branch 'infoleaks'
authorDavid S. Miller <davem@davemloft.net>
Sun, 7 Apr 2013 20:42:40 +0000 (16:42 -0400)
committerDavid S. Miller <davem@davemloft.net>
Sun, 7 Apr 2013 20:42:40 +0000 (16:42 -0400)
commitf89e8a6432409c6cbd5c2b6bb90ea694fd558de3
tree01aaa7cb29147cba0fcc1202a03bbf1af598be62
parent50a75a8914539c5dcd441c5f54d237a666a426fd
parentd5e0d0f607a7a029c6563a0470d88255c89a8d11
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 <davem@davemloft.net>