lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 18 Feb 2016 08:07:07 +0000 (GMT) From: EunTaik Lee <eun.taik.lee@...sung.com> To: Laura Abbott <labbott@...hat.com>, ÀÌÀºÅà <eun.taik.lee@...sung.com>, "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "arve@...roid.com" <arve@...roid.com>, "riandrews@...roid.com" <riandrews@...roid.com>, "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>, "gioh.kim@....com" <gioh.kim@....com>, "dan.carpenter@...cle.com" <dan.carpenter@...cle.com>, Rohit Kumar <rohit.kr@...sung.com>, "sriram@...irs.net.in" <sriram@...irs.net.in>, "shawn.lin@...k-chips.com" <shawn.lin@...k-chips.com>, "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: Re: [RFC PATCH] staging/android/ion : fix a race condition in the ion driver 2016-02-18 3:54 GMT+09:00 Laura Abbott <labbott@...hat.com>: > On 02/16/2016 10:32 PM, EunTaik Lee wrote: >> There was a use-after-free problem in the ion driver. >> >> The problem is detected as an unaligned access in the >> spin lock functions since it uses load exclusive >> instruction. In some cases it corrupts the slub's >> free pointer which causes a unaligned access to the >> next free pointer.(thus the kmalloc function returns >> a pointer like ffffc0745b4580aa). And it causes lots of other >> hard-to-debug problems. >> >> This symptom is caused since the first member in the >> ion_handle structure is the reference count and the >> ion driver decrements the reference after it has been >> freed. >> >> To fix this problem client->lock mutex is extended >> to protect all the codes that uses the handle. >> > > This describes the symptoms very well but what's the actual > race condition? The actual race condition was in case ION_IOC_FREE of ion_ioctl() function. A handle has ref count of 1 and two tasks on different cpus calls ION_IOC_FREE simultaneously. cpu 0 cpu 1 ------------------------------------------------------- ion_handle_get_by_id() (ref == 2) ion_handle_get_by_id() (ref == 3) ion_free() (ref == 2) ion_handle_put() (ref == 1) ion_free() (ref == 0 so ion_handle_destroy() is called and the handle is freed.) ion_handle_put() is called and it decreases the slub's next free pointer So it's basically a double free on the userspace. But I made this patch since I don't think we should take a risk of such a malicious code to mess up the kernel. > Also what tree did you generate this against? It doesn't > seem to apply. The patch was generated against the stable-kernel. I will resend the patch using the latest stable-kernel along with a silly mistake that I've made when merging the patch(made against 3.18.20) to the stable-kernel. (Thank you Julia <julia.lawall@...6.fr> for pointing out my mistake)
Powered by blists - more mailing lists