Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948222AbbGaV5k (ORCPT ); Fri, 31 Jul 2015 17:57:40 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45766 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752107AbbGaTm1 (ORCPT ); Fri, 31 Jul 2015 15:42:27 -0400 From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lennert Buytenhek , Alexander Aring , Marcel Holtmann Subject: [PATCH 4.1 023/267] ieee802154: Fix sockaddr_ieee802154 implicit padding information leak. Date: Fri, 31 Jul 2015 12:37:54 -0700 Message-Id: <20150731194002.673777700@linuxfoundation.org> X-Mailer: git-send-email 2.5.0 In-Reply-To: <20150731194001.933895871@linuxfoundation.org> References: <20150731194001.933895871@linuxfoundation.org> User-Agent: quilt/0.64 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2743 Lines: 81 4.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lennert Buytenhek 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 Acked-by: Alexander Aring Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman --- 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); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/