From: <gregkh@linuxfoundation.org>
To: buytenh@wantstofly.org, alex.aring@gmail.com,
gregkh@linuxfoundation.org, marcel@holtmann.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "ieee802154: Fix sockaddr_ieee802154 implicit padding information leak." has been added to the 4.1-stable tree
Date: Wed, 29 Jul 2015 17:25:46 -0700 [thread overview]
Message-ID: <1438215946207182@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
ieee802154: Fix sockaddr_ieee802154 implicit padding information leak.
to the 4.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ieee802154-fix-sockaddr_ieee802154-implicit-padding-information-leak.patch
and it can be found in the queue-4.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 8a70cefa3037d62e7c0b6068a66675def1a330c9 Mon Sep 17 00:00:00 2001
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Wed, 3 Jun 2015 10:50:19 +0300
Subject: ieee802154: Fix sockaddr_ieee802154 implicit padding information leak.
From: Lennert Buytenhek <buytenh@wantstofly.org>
commit 8a70cefa3037d62e7c0b6068a66675def1a330c9 upstream.
The AF_IEEE802154 sockaddr looks like this:
struct sockaddr_ieee802154 {
sa_family_t family; /* AF_IEEE802154 */
struct ieee802154_addr_sa addr;
};
struct ieee802154_addr_sa {
int addr_type;
u16 pan_id;
union {
u8 hwaddr[IEEE802154_ADDR_LEN];
u16 short_addr;
};
};
On most architectures there will be implicit structure padding here,
in two different places:
* In struct sockaddr_ieee802154, two bytes of padding between 'family'
(unsigned short) and 'addr', so that 'addr' starts on a four byte
boundary.
* In struct ieee802154_addr_sa, two bytes at the end of the structure,
to make the structure 16 bytes.
When calling recvmsg(2) on a PF_IEEE802154 SOCK_DGRAM socket, the
ieee802154 stack constructs a struct sockaddr_ieee802154 on the
kernel stack without clearing these padding fields, and, depending
on the addr_type, between four and ten bytes of uncleared kernel
stack will be copied to userspace.
We can't just insert two 'u16 __pad's in the right places and zero
those before copying an address to userspace, as not all architectures
insert this implicit padding -- from a quick test it seems that avr32,
cris and m68k don't insert this padding, while every other architecture
that I have cross compilers for does insert this padding.
The easiest way to plug the leak is to just memset the whole struct
sockaddr_ieee802154 before filling in the fields we want to fill in,
and that's what this patch does.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ieee802154/socket.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -739,6 +739,12 @@ static int dgram_recvmsg(struct sock *sk
sock_recv_ts_and_drops(msg, sk, skb);
if (saddr) {
+ /* Clear the implicit padding in struct sockaddr_ieee802154
+ * (16 bits between 'family' and 'addr') and in struct
+ * ieee802154_addr_sa (16 bits at the end of the structure).
+ */
+ memset(saddr, 0, sizeof(*saddr));
+
saddr->family = AF_IEEE802154;
ieee802154_addr_to_sa(&saddr->addr, &mac_cb(skb)->source);
*addr_len = sizeof(*saddr);
Patches currently in stable-queue which might be from buytenh@wantstofly.org are
queue-4.1/ieee802154-fix-sockaddr_ieee802154-implicit-padding-information-leak.patch
reply other threads:[~2015-07-30 0:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1438215946207182@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alex.aring@gmail.com \
--cc=buytenh@wantstofly.org \
--cc=marcel@holtmann.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.