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

[Mathias Krause <minipli () googlemail com>]

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.


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.


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.

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


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