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

[Greg KH]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/