[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1365335522-29931-1-git-send-email-minipli@googlemail.com>
Date: Sun, 7 Apr 2013 13:51:46 +0200
From: Mathias Krause <minipli@...glemail.com>
To: "David S. Miller" <davem@...emloft.net>
Cc: netdev@...r.kernel.org,
Allan Stephens <allan.stephens@...driver.com>,
Aloisio Almeida Jr <aloisio.almeida@...nbossa.org>,
Andy King <acking@...are.com>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Dmitry Torokhov <dtor@...are.com>,
George Zhang <georgezhang@...are.com>,
Gustavo Padovan <gustavo@...ovan.org>,
Johan Hedberg <johan.hedberg@...il.com>,
Jon Maloy <jon.maloy@...csson.com>,
Lauro Ramos Venancio <lauro.venancio@...nbossa.org>,
Marcel Holtmann <marcel@...tmann.org>,
Ralf Baechle <ralf@...ux-mips.org>,
Samuel Ortiz <sameo@...ux.intel.com>,
Samuel Ortiz <samuel@...tiz.org>,
Sjur Braendeland <sjur.brandeland@...ricsson.com>,
Ursula Braun <ursula.braun@...ibm.com>,
Brad Spengler <spender@...ecurity.net>,
Mathias Krause <minipli@...glemail.com>
Subject: [PATCH 00/16] info leak fixes in recvmsg
Hi Dave,
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 :/
Please apply!
Mathias Krause (16):
atm: update msg_namelen in vcc_recvmsg()
ax25: fix info leak via msg_name in ax25_recvmsg()
Bluetooth: fix possible info leak in bt_sock_recvmsg()
Bluetooth: RFCOMM - Fix missing msg_namelen update in
rfcomm_sock_recvmsg()
Bluetooth: SCO - Fix missing msg_namelen update in sco_sock_recvmsg()
caif: Fix missing msg_namelen update in caif_seqpkt_recvmsg()
irda: Fix missing msg_namelen update in irda_recvmsg_dgram()
iucv: Fix missing msg_namelen update in iucv_sock_recvmsg()
l2tp: fix info leak in l2tp_ip6_recvmsg()
llc: Fix missing msg_namelen update in llc_ui_recvmsg()
netrom: fix info leak via msg_name in nr_recvmsg()
NFC: llcp: fix info leaks via msg_name in llcp_sock_recvmsg()
rose: fix info leak via msg_name in rose_recvmsg()
tipc: fix info leaks via msg_name in recv_msg/recv_stream
VSOCK: vmci - fix possible info leak in
vmci_transport_dgram_dequeue()
VSOCK: Fix missing msg_namelen update in vsock_stream_recvmsg()
net/atm/common.c | 2 ++
net/ax25/af_ax25.c | 1 +
net/bluetooth/af_bluetooth.c | 4 ++--
net/bluetooth/rfcomm/sock.c | 1 +
net/bluetooth/sco.c | 1 +
net/caif/caif_socket.c | 2 ++
net/irda/af_irda.c | 2 ++
net/iucv/af_iucv.c | 2 ++
net/l2tp/l2tp_ip6.c | 1 +
net/llc/af_llc.c | 2 ++
net/netrom/af_netrom.c | 1 +
net/nfc/llcp/sock.c | 3 +++
net/rose/af_rose.c | 1 +
net/tipc/socket.c | 7 +++++++
net/vmw_vsock/af_vsock.c | 2 ++
net/vmw_vsock/vmci_transport.c | 3 ++-
16 files changed, 32 insertions(+), 3 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists