diff options
author | David S. Miller <davem@davemloft.net> | 2013-04-08 00:42:40 +0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2013-04-08 00:42:40 +0400 |
commit | f89e8a6432409c6cbd5c2b6bb90ea694fd558de3 (patch) | |
tree | 01aaa7cb29147cba0fcc1202a03bbf1af598be62 /MAINTAINERS | |
parent | 50a75a8914539c5dcd441c5f54d237a666a426fd (diff) | |
parent | d5e0d0f607a7a029c6563a0470d88255c89a8d11 (diff) | |
download | linux-f89e8a6432409c6cbd5c2b6bb90ea694fd558de3.tar.xz |
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>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions