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 netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
