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

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+rthh9xW3Wcmp+sOax69+GXyre151359XcvpcOKtTA6w3w6Kw@mail.gmail.com>
Date: Tue, 5 Mar 2013 21:52:30 +0100
From: Mathias Krause <minipli@...glemail.com>
To: Kurt Seifried <kseifried@...hat.com>, oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs

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

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.