oss-sec mailing list archives
Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs
From: Kurt Seifried <kseifried () redhat com>
Date: Wed, 06 Mar 2013 01:46:49 -0700
-----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. ;)
CVE ID's prompt people to back port these security fixes which is a good thing indeed =).
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.
can you provide the full git id/link to these? Also were they all discovered by the same researcher?
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.
can you provide the full git id/link to these? Also were they all discovered by the same researcher?
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.)?
Yes please. Much like DNA fragments you can potentially string them together to reveal larger things.
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) iQIcBAEBAgAGBQJRNwJ5AAoJEBYNRVNeJnmTVtYQAMSwhmnF4hScjVRMmJuc/mcM ExgC7R1khhxIG5rPU+ZwVvLnfO0hby2oRIIkFf/2Aaj4mMXe5iBLzO3xdgWS1Ekv M4PE57f8X+4G+9PaYWW1ebWDuf1HAVc8fxneZ1aBC3xPEg+VEgutow8To4x5rwyp Y0iO4OsMU6nHLj2dDodKXlIvzoSm7Vdrgx+GE96fAQTxHgsamyKBP/cDzl7QwowZ dXZEJ1pK6H2pMVbutKLYQmUMhXRCtNajZaqRbysvoLrnjcY0G56Gf+pZUWPWaOqf K2g81VcoG4buc1zoDCAcmUBHSM69g3gN2Rz+Wvqx1G9ABQyIaSpuyaP4cLLHTtPn AS4pql+TJMyvP+yWDSM3a8RGRaO+9jzdJCrXVDrq5mdEmjkqgAT7R3XOvLTouJp8 0QnGAYczKf09PeRuaficD8eg5GUGYbrIvVp00qG9wBcPhvVNNTJrsi/rjbiroW/g KDQzlKqxKbixaxj4tFtGpyeDXcKR1weT9JLG21IZmMA3NLhGuvUbSPpdL3Yqbshh jGtxy0QIcLGl3j+mYwsgXYt26oCg80tFrYXKoyBlD/D+7NjUDOfPReauB6nlsAiU +KWO70sxeIjbRGqmJD1/scIzzBVZKPJ/rdM5Y2A+dhioVg7vAG1RxyxHY+nHMpGt wX0XTKmw9WnfdDe4U0T/ =ldnf -----END PGP SIGNATURE-----
Current thread:
- CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Mathias Krause (Mar 05)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Kurt Seifried (Mar 06)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Mathias Krause (Mar 06)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Kurt Seifried (Mar 07)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Solar Designer (Mar 07)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Kurt Seifried (Mar 07)
- RE: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Christey, Steven M. (Mar 07)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Solar Designer (Mar 07)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Petr Matousek (Mar 07)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Kurt Seifried (Mar 07)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Thomas Biege (Mar 08)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Solar Designer (Mar 07)
- Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs Kurt Seifried (Mar 06)