Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/2013 01:52 PM, Mathias Krause wrote:
> Hi Kurt,
>
> I don't care much about info leaks beyond merely fixing them. But 
> Alexander asked me to request a CVE ID for the recent crypto fix
> of mine and as I did quite a few of such fixes in the recent past,
> I'll just list them all here. The information might be a bit scarce
> for a CVE ID request but as I don't expect any CVE IDs anyway, I
> didn't wanted to do too much unnecessary work. ;)
>
> 9a5467b crypto: user - fix info leaks in report API
>
> This is quite a big info leak of heap, stack and .text memory. No 
> crypto material, though. Also, as the crypto user API is protected
> by capable(CAP_NET_ADMIN), it's not as critical as is might sound
> on the first sight. It affects all versions from the introduction
> of the crypto user API -- that is v3.2 - v3.8.

Please use CVE-2013-1825 for this issue.


Bundling the following into a single CVE:

> Older info leak fixes follow. All of them ended up in v3.6 and
> were backported to the stable/longterm kernels at the time:
>
> ecd7918 xfrm_user: ensure user supplied esn replay window is valid 
> What: Leaks up to ~3.5kb heap memory. Was protected by 
> capable(CAP_NET_ADMIN) at the time.
>
> 1f86840 xfrm_user: fix info leak in copy_to_user_tmpl() What: Minor
> leak of stack memory. Was protected by capable(CAP_NET_ADMIN) at
> the time.
>
> 7b78983 xfrm_user: fix info leak in copy_to_user_policy() What:
> Minor leak of heap memory. Was protected by capable(CAP_NET_ADMIN)
> at the time.
>
> f778a63 xfrm_user: fix info leak in copy_to_user_state() What:
> Minor leak of heap memory. Was protected by capable(CAP_NET_ADMIN)
> at the time.
>
> 4c87308 xfrm_user: fix info leak in copy_to_user_auth() What: Leak
> of heap memory. Was protected by capable(CAP_NET_ADMIN) at the
> time.
>
> 43da5f2 net: fix info leak in compat dev_ifconf() What: Minor leak
> of stack memory.
>
> 2d8a041 ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT) 
> What: Minor leak of stack memory.
>
> 7b07f8e dccp: fix info leak via
> getsockopt(DCCP_SOCKOPT_CCID_TX_INFO) What: Minor leak of stack
> memory.
>
> 3592aae llc: fix info leak via getsockname() What: Major leak of
> stack memory (up to 128 bytes).
>
> 04d4fbc l2tp: fix info leak via getsockname() What: Minor leak of
> stack memory.
>
> 792039c Bluetooth: L2CAP - Fix info leak via getsockname() What:
> Minor leak of stack memory.
>
> 9344a97 Bluetooth: RFCOMM - Fix info leak via getsockname() What:
> Minor leak of stack memory.
>
> f9432c5 Bluetooth: RFCOMM - Fix info leak in
> ioctl(RFCOMMGETDEVLIST) What: Minor leak of heap memory.
>
> 9ad2de4 Bluetooth: RFCOMM - Fix info leak in
> getsockopt(BT_SECURITY) What: Minor leak of stack memory.
>
> 3f68ba0 Bluetooth: HCI - Fix info leak via getsockname() What:
> Minor leak of stack memory.
>
> e15ca9a Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER) 
> What: Minor leak of stack memory.
>
> 3c0c5cf atm: fix info leak via getsockname() What: Minor leak of
> stack memory.
>
> e862f1a atm: fix info leak in getsockopt(SO_ATMPVC) What: Minor
> leak of stack memory.
>
> a117dac net/tun: fix ioctl() based info leaks What: Leak of 36
> bytes of stack memory.
>
> 0143fc5 udf: avoid info leak on export What: Minor leak of heap
> memory.
>
> fe685aa isofs: avoid info leak on export What: Minor leak of heap
> memory.

Please use CVE-2012-6138 for these issues.

> Now do follow a few NULL ptr derefs ending up in privilege
> escalation if a user is able to map page 0 or probably a DoS
> otherwise. Also those have all been fixed in v3.6 and backported to
> the corresponding stable/longterm kernels at the time:
>
> 864745d xfrm_user: return error pointer instead of NULL What: Wrong
> return of NULL leads to wrong path in calling function leading to
> NULL pointer deref of skb.

Please use CVE-2013-1826 for this issue.

> 276bdb8 dccp: check ccid before dereferencing What: Missing NULL
> pointer check leads to NULL function pointer.

Please use CVE-2013-1827 for this issue.


> That's all. Enough, I guess ;)
>
> While we are at it: Do we care about getting CVE IDs for info
> leaks? If so, all of them or only for the ones with leaks above a
> certain threshold (>= 16 bytes, e.g.)?
>
> Regards, Mathias

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJROFpBAAoJEBYNRVNeJnmT/SwP/37qcH9dRMXl6TYl/tZNuyr3
qBjFI/waxxiJt2x5abAeFXJ423+Lg30ZrkuuiUkLaNRRa+U4pDkInKw9xsigvm4D
+JKXmEI0qwVfjRg7dDQY0HSWUaNwlXbr2roOw2ioilukkGcAcWIlKErP0rrbN8u9
JSj7uE77+MN5MuCevI2u5DWBY1iuGwzzvRFf3DYCcE+ceha8Iwn0AdR3jPtYgrpA
jJ+zew9OlAp65zhcJ47SQ5X9hmBNglWKr6ej9cNn/NLdfcMott1+kggNyU5djtCY
lwAHZ3jQT9+4m+kDZiG+8QpMyAQucitCyudehk9oryWgU9Rc6jrwYeA5FWpJEFpJ
ujZB3diGzqt8K8GsMzoIisNYr/10tLr2ummBSlB1fCzyITFJG4aSQETjtVv5B5/I
fIjY3nQ8CXs8UDCAFVdPffQgByeFVxPdBf9xI8nqo36DSpHSBWSI1XZcOscpAYRI
GIhpN4TmzAja90l6LxH0p1oxrgL0mzmIkud29UrwntLfCHxuzQ42Wj1hKNKZdRN7
FxPXE8J2g4EaAFzO4jHun7kFQO6ME9ThPac82p/2kY2VjW15VE9iV5jJdSGxzH1L
5Em1s2A4yChVwXZFVjH6I0A4h4AE3CPkG6NuHOBVo5/Bn3vDc4n1PXG/c8EF5AFf
kIERn7KKBOTAwHQ5UheK
=bmBV
-----END PGP SIGNATURE-----