Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri,  5 Jun 2015 17:29:22 -0400 (EDT)
Subject: Re: CVE Request: Linux Kernel Ozwpan Driver - Remote packet-of-death vulnerabilities

Hash: SHA1

> 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.
> 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.

Determining the right number of CVE IDs is typically not based on
looking at the number of impacts. We have reorganized your request to
account for that.

> 1. A remote packet can be sent, resulting in funny subtractions of
> signed integers, which causes a memcpy(kernel_heap,
> network_user_buffer, -network_user_provided_length).

In this case, the primary problem was using the wrong integer data
type. No code needed to be added; the only change was from signed to
unsigned. Use CVE-2015-4001.

> 1. A remote packet can be sent, resulting in funny subtractions of
> signed integers, which causes a memcpy(kernel_heap,
> network_user_buffer, -network_user_provided_length).

> 3. A remote packet can be sent, resulting in a funny subtraction,
> causing an insanely big loop to lock up the kernel:

In these two cases, the primary problem was lack of a check for
whether a length value (elt->length or len) was too small. (A
secondary factor is that the data types needed to be changed to
implement this check.) The nature of the later code results in two
different types of impacts, but the two issues can still share the
same CVE ID. Use CVE-2015-4002.

> 2. A remote packet can be sent, resulting in divide-by-zero in
> softirq, causing hard crash:

Use CVE-2015-4003.

> 4. Multiple out-of-bounds reads, resulting in possible information
> leakage, explained in the last paragraph of the introductory email
> here:

> The maintainer has not yet written a patch to fix this issue, so it
> remains an open case.

> 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.

The "actual length ... is never actually consulted" issues are
essentially what is described on the page. Use CVE-2015-4004
for all of these CWE-130 issues. An issue can, of course, have an
out-of-bounds read impact but not be a CWE-130 issue.

> 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.

If the maintainers (or any researcher) decide to disclose a
security-relevant out-of-bounds read issue that is outside the defined
scope of CVE-2015-4004, then they're certainly welcome to ask for
their own CVE ID.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ