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.