From: Mathias Krause <minipli@googlemail.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org,
Allan Stephens <allan.stephens@windriver.com>,
Aloisio Almeida Jr <aloisio.almeida@openbossa.org>,
Andy King <acking@vmware.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Dmitry Torokhov <dtor@vmware.com>,
George Zhang <georgezhang@vmware.com>,
Gustavo Padovan <gustavo@padovan.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
Jon Maloy <jon.maloy@ericsson.com>,
Lauro Ramos Venancio <lauro.venancio@openbossa.org>,
Marcel Holtmann <marcel@holtmann.org>,
Ralf Baechle <ralf@linux-mips.org>,
Samuel Ortiz <sameo@linux.intel.com>,
Samuel Ortiz <samuel@sortiz.org>,
Sjur Braendeland <sjur.brandeland@stericsson.com>,
Ursula Braun <ursula.braun@de.ibm.com>,
Brad Spengler <spender@grsecurity.net>,
Mathias Krause <minipli@googlemail.com>
Subject: [PATCH 00/16] info leak fixes in recvmsg
Date: Sun, 7 Apr 2013 13:51:46 +0200 [thread overview]
Message-ID: <1365335522-29931-1-git-send-email-minipli@googlemail.com> (raw)
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
next reply other threads:[~2013-04-07 11:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-07 11:51 Mathias Krause [this message]
2013-04-07 11:51 ` [PATCH 01/16] atm: update msg_namelen in vcc_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 02/16] ax25: fix info leak via msg_name in ax25_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 03/16] Bluetooth: fix possible info leak in bt_sock_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 04/16] Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 05/16] Bluetooth: SCO - Fix missing msg_namelen update in sco_sock_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 06/16] caif: Fix missing msg_namelen update in caif_seqpkt_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 07/16] irda: Fix missing msg_namelen update in irda_recvmsg_dgram() Mathias Krause
2013-04-07 11:51 ` [PATCH 08/16] iucv: Fix missing msg_namelen update in iucv_sock_recvmsg() Mathias Krause
2013-04-08 11:14 ` Ursula Braun
2013-04-07 11:51 ` [PATCH 09/16] l2tp: fix info leak in l2tp_ip6_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 10/16] llc: Fix missing msg_namelen update in llc_ui_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 11/16] netrom: fix info leak via msg_name in nr_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 12/16] NFC: llcp: fix info leaks via msg_name in llcp_sock_recvmsg() Mathias Krause
2013-04-07 11:51 ` [PATCH 13/16] rose: fix info leak via msg_name in rose_recvmsg() Mathias Krause
2013-04-07 11:52 ` [PATCH 14/16] tipc: fix info leaks via msg_name in recv_msg/recv_stream Mathias Krause
2013-04-07 11:52 ` [PATCH 15/16] VSOCK: vmci - fix possible info leak in vmci_transport_dgram_dequeue() Mathias Krause
2013-04-07 11:52 ` [PATCH 16/16] VSOCK: Fix missing msg_namelen update in vsock_stream_recvmsg() Mathias Krause
2013-04-07 20:31 ` [PATCH 00/16] info leak fixes in recvmsg David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1365335522-29931-1-git-send-email-minipli@googlemail.com \
--to=minipli@googlemail.com \
--cc=acking@vmware.com \
--cc=acme@ghostprotocols.net \
--cc=allan.stephens@windriver.com \
--cc=aloisio.almeida@openbossa.org \
--cc=davem@davemloft.net \
--cc=dtor@vmware.com \
--cc=georgezhang@vmware.com \
--cc=gustavo@padovan.org \
--cc=johan.hedberg@gmail.com \
--cc=jon.maloy@ericsson.com \
--cc=lauro.venancio@openbossa.org \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=sameo@linux.intel.com \
--cc=samuel@sortiz.org \
--cc=sjur.brandeland@stericsson.com \
--cc=spender@grsecurity.net \
--cc=ursula.braun@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).