Re: [oss-security] [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities

From: Greg KH
Date: Wed May 13 2015 - 14:43:43 EST

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/ to properly notify the correct


greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at