There is a use-after-free case with below call stack.
pid_nr_ns+0x10/0x38
cgroup_pidlist_start+0x144/0x400
cgroup_seqfile_start+0x1c/0x24
kernfs_seq_start+0x54/0x90
seq_read+0x15c/0x3a8
kernfs_fop_read+0x38/0x160
__vfs_read+0x28/0xc8
vfs_read+0x84/0xfc
A task in the cg_list was dying and the grou
There is a use-after-free problem in the ion driver.
This is caused by a race condition in the 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
--
shawn.lin@rock-
> chips.com; de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org;
> eunt...@gmail.com
> Subject: Re: [PATCH v3] staging/android/ion : fix a race condition in the
> ion driver
>
> On 02/23/2016 08:38 PM, EunTaik Lee wrote:
> > There is a use-after-free
There is a use-after-free problem in the ion driver.
This is caused by a race condition in the 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
---
t.in; shawn.lin@rock-
> chips.com; de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org;
> eunt...@gmail.com
> Subject: Re: [PATCH v2] staging/android/ion : fix a race condition in the
> ion driver
>
> On 02/19/2016 04:03 AM, EunTaik Lee wrote:
> > There is a use-after-free
There is a use-after-free problem in the ion driver.
This is caused by a race condition in the 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
---
2016-02-17 2:11 GMT+09:00 Catalin Marinas :
> On Tue, Feb 16, 2016 at 04:44:38AM +0000, EunTaik Lee wrote:
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 19211c4..a5ebb99 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>>
There is a use-after-free problem in the ion driver.
This is caused by a race condition in the 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
---
2016-02-18 3:54 GMT+09:00 Laura Abbott :
> 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
>> instr
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 fu
Userspace memory is mapped as below:
F2A7F000--F2A7 Normal Memory
F2A8--F2A80FFF Device nGnRnE
And that userspace application makes a system call
as below:
-009 |do_strncpy_from_user(inline)
-009 |strncpy_from_user()
-010 |getname_flags()
-011 |user_path_at_empty()
-012 |user_path_at()
-0
> How do you end up with Device nGnRnE in user space? I thought we should
> have got some guard page.
I guess it is a device file that is mmaped in the user space and later remapped
in the kernel
using pgprot_noncached().
I can't find the code that inserts a guard page in between vma's can you
> How do you end up with Device nGnRnE in user space? I thought we should
> have got some guard page.
I guess it is a device file that is mmaped in the user space and later remapped
in the kernel
using pgprot_noncached().
I can't find the code that inserts a guard page in between vma's can you p
Userspace memory is mapped as below:
F2A7F000--F2A7 Normal Memory
F2A8--F2A80FFF Device nGnRnE
And that userspace application makes a system call
as below:
-009 |do_strncpy_from_user(inline)
-009 |strncpy_from_user()
-010 |getname_flags()
-011 |user_path_at_empty()
-012 |user_path_at()
-0
Userspace memory is mapped as below:
F2A7F000--F2A7 Normal Memory
F2A8--F2A80FFF Device nGnRnE
And that userspace application makes a system call
as below:
-009 |do_strncpy_from_user(inline)
-009 |strncpy_from_user()
-010 |getname_flags()
-011 |user_path_at_empty()
-012 |user_path_at()
-0
When a task that calls state_store() to suspend
the device has used up most of its time slice,
suspend sometimes take too long. (User noticeable)
Suspend/resume is a system wide operation.
So, instead of depending on a userspace task's time
slice, let kworker do the work to avoid a long wait
on th
ezing of tasks resumed after other tasks went out of the runqueue.
I have tested with the lowest nice value but the problem was still, although
less, reproducible.
Best Regards,
Euntaik Lee
> Instead of replicating code in state_store here, does it make sense to
> move into a common part, so that fixes/optimization can be done in one
> place?
> Also why another config? If this has proven benefit then it can be
> default path.
I agree. I will resend the patch if this patch is agreed t
>> When a task that calls state_store() to suspend
>> the device has used up most of its time slice,
>> suspend sometimes take too long. (User noticeable)
>>
>> Suspend/resume is a system wide operation.
>> So, instead of depending on a userspace task's time
>> slice, let kworker do the work to a
The problem was on 3.10.49.
I carefully looked up the patches again and found out that there was
a patch on 3.18 that will solve the problem
commit e4a60d139060975eb956717e4f63ae348d4d8cc5
sysfs: driver core: Fix glue dir race condition by gdp_mutex
Sorry for bothering you.
Thanks,
Eun Taik
>
>The bus that the device is on should prevent this, why isn't that
>working for you? What type of device/bus do you see this problem on?
The device is a firmware class device on a virtual bus.
>> Signed-off-by: eun.taik.lee
>
>We need a "real" name here, I don't think your name has '.' in it
There is a possible race condition when a device
is added while another device with the same parent
, with ref count of one, is deleted.
CPU0CPU1
device_add() device_del()
get_device_parent() put_device(parent);
kobj = kobject_get(k); kobject_put()
kref_put()
22 matches
Mail list logo
