[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150605212922.123888BC10A@smtpvmsrv1.mitre.org>
Date: Fri, 5 Jun 2015 17:29:22 -0400 (EDT)
From: cve-assign@...re.org
To: Jason@...c4.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request: Linux Kernel Ozwpan Driver - Remote packet-of-death vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
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).
>
> https://lkml.org/lkml/2015/5/13/744
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?id=b1bb5b49373b61bf9d2c73a4d30058ba6f069e4c
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).
>
> https://lkml.org/lkml/2015/5/13/740
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?id=d114b9fe78c8d6fc6e70808c2092aa307c36dc8e
> 3. A remote packet can be sent, resulting in a funny subtraction,
> causing an insanely big loop to lock up the kernel:
>
> https://lkml.org/lkml/2015/5/13/742
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?id=9a59029bc218b48eff8b5d4dde5662fd79d3e1a8
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:
> https://lkml.org/lkml/2015/5/13/741
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?&id=04bf464a5dfd9ade0dda918e44366c2c61fce80b
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:
> https://lkml.org/lkml/2015/5/13/739
> 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
http://cwe.mitre.org/data/definitions/130.html 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVchQ8AAoJEKllVAevmvmsDikH/2bokNcp2iLCX6V+hudRyavo
te5PksfYBRHVRUPoboMx3nchFIAHU4o4ZxTpSvbdt6/WNr2xTRra0tL7hl1tXDA3
RoFOxQtzjE5R80E/yWkxphvnsVMLDEUJKNt0ojI9xjGiFGD/XgyOGHnrZU26/Z9V
hrjezTzAqLH8pN43byarVHBDv8QyB7e5vKljWvIKW6zWldnpUnPX8HRnIILxBDsK
AkvjPLFGekPo0YfLNN9s1DgKg/Bjp+fHbK+1XckbA73furworOiI4z5O8yCzDhi5
Ee4vzJBGlcCJU6YcoLO0Gz8nnozH89JvJXecCqDihGk1jrMHfVHFN3HMzu/Cel4=
=ge8R
-----END PGP SIGNATURE-----
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.
