[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150513184331.GA1847@kroah.com>
Date: Wed, 13 May 2015 11:43:31 -0700
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Cc: shigekatsu.tateno@...el.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, "Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH 0/4] ozwpan: Four remote packet-of-death
vulnerabilities
On Wed, May 13, 2015 at 08:33:30PM +0200, Jason A. Donenfeld wrote:
> The ozwpan driver accepts network packets, parses them, and converts
> them into various USB functionality. There are numerous security
> vulnerabilities in the handling of these packets. Two of them result in
> a memcpy(kernel_buffer, network_packet, -length), one of them is a
> divide-by-zero, and one of them is a loop that decrements -1 until it's
> zero.
>
> I've written a very simple proof-of-concept for each one of these
> vulnerabilities to aid with detecting and fixing them. The general
> operation of each proof-of-concept code is:
>
> - Load the module with:
> # insmod ozwpan.ko g_net_dev=eth0
> - Compile the PoC with ozprotocol.h from the kernel tree:
> $ cp /path/to/linux/drivers/staging/ozwpan/ozprotocol.h ./
> $ gcc ./poc.c -o ./poc
> - Run the PoC:
> # ./poc eth0 [mac-address]
>
> These PoCs should also be useful to the maintainers for testing out
> constructing and sending various other types of malformed packets against
> which this driver should be hardened.
>
> Please assign CVEs for these vulnerabilities. I believe the first two
> patches of this set can receive one CVE for both, and the remaining two
> can receive one CVE each.
>
>
> On a slightly related note, there are several other vulnerabilities in
> this driver that are worth looking into. When ozwpan receives a packet,
> it casts the packet into a variety of different structs, based on the
> value of type and length parameters inside the packet. When making these
> casts, and when reading bytes based on this length parameter, the actual
> length of the packet in the socket buffer is never actually consulted. As
> such, it's very likely that a packet could be sent that results in the
> kernel reading memory in adjacent buffers, resulting in an information
> leak, or from unpaged addresses, resulting in a crash. In the former case,
> it may be possible with certain message types to actually send these
> leaked adjacent bytes back to the sender of the packet. So, I'd highly
> recommend the maintainers of this driver go branch-by-branch from the
> initial rx function, adding checks to ensure all reads and casts are
> within the bounds of the socket buffer.
>
> Jason A. Donenfeld (4):
> ozwpan: Use proper check to prevent heap overflow
> ozwpan: Use unsigned ints to prevent heap overflow
> ozwpan: divide-by-zero leading to panic
> ozwpan: unchecked signed subtraction leads to DoS
>
> drivers/staging/ozwpan/ozhcd.c | 8 ++++----
> drivers/staging/ozwpan/ozusbif.h | 4 ++--
> drivers/staging/ozwpan/ozusbsvc1.c | 11 +++++++++--
> 3 files changed, 15 insertions(+), 8 deletions(-)
Any reason you didn't cc: the maintainer who could actually apply these
to the kernel tree?
Please use scripts/get_maintainer.pl to properly notify the correct
people.
thanks,
greg k-h
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
