syzbot has found a reproducer for the following crash on:
HEAD commit:aa4330e15c26 Merge tag 'devicetree-fixes-for-4.20-2' of gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17abaa4740
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:aa4330e15c26 Merge tag 'devicetree-fixes-for-4.20-2' of gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17abaa4740
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:3541833fd1f2 Merge tag 's390-4.20-2' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16d3cad540
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:3541833fd1f2 Merge tag 's390-4.20-2' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16d3cad540
kernel config:
On 10/26, Kees Cook wrote:
>
> On Thu, Oct 25, 2018 at 2:01 PM, Oleg Nesterov wrote:
> > On 10/25, Oleg Nesterov wrote:
> >> perhaps it needs some changes too. I even have a vague feeling that I have
> >> already
> >> blamed this function some time ago...
> >
> > Heh, yes, 3 years ago ;)
> >
> >
On 10/26, Kees Cook wrote:
>
> On Thu, Oct 25, 2018 at 2:01 PM, Oleg Nesterov wrote:
> > On 10/25, Oleg Nesterov wrote:
> >> perhaps it needs some changes too. I even have a vague feeling that I have
> >> already
> >> blamed this function some time ago...
> >
> > Heh, yes, 3 years ago ;)
> >
> >
On Thu, Oct 25, 2018 at 2:01 PM, Oleg Nesterov wrote:
> On 10/25, Oleg Nesterov wrote:
>> perhaps it needs some changes too. I even have a vague feeling that I have
>> already
>> blamed this function some time ago...
>
> Heh, yes, 3 years ago ;)
>
>
On Thu, Oct 25, 2018 at 2:01 PM, Oleg Nesterov wrote:
> On 10/25, Oleg Nesterov wrote:
>> perhaps it needs some changes too. I even have a vague feeling that I have
>> already
>> blamed this function some time ago...
>
> Heh, yes, 3 years ago ;)
>
>
On 10/27, Tetsuo Handa wrote:
>
> On 2018/10/26 23:39, Oleg Nesterov wrote:
> > On 10/26, Tetsuo Handa wrote:
> >> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
> >> when someone tried to attach on p2, p2->real_parent was pointing to already
> >> (or about to be) freed p1.
On 10/27, Tetsuo Handa wrote:
>
> On 2018/10/26 23:39, Oleg Nesterov wrote:
> > On 10/26, Tetsuo Handa wrote:
> >> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
> >> when someone tried to attach on p2, p2->real_parent was pointing to already
> >> (or about to be) freed p1.
On 2018/10/26 23:39, Oleg Nesterov wrote:
> On 10/26, Tetsuo Handa wrote:
>> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
>> when someone tried to attach on p2, p2->real_parent was pointing to already
>> (or about to be) freed p1.
>
> I don't see a difference.
>
> If p1
On 2018/10/26 23:39, Oleg Nesterov wrote:
> On 10/26, Tetsuo Handa wrote:
>> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
>> when someone tried to attach on p2, p2->real_parent was pointing to already
>> (or about to be) freed p1.
>
> I don't see a difference.
>
> If p1
On 10/26, Tetsuo Handa wrote:
>
> On 2018/10/26 22:04, Oleg Nesterov wrote:
> >> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
> >> when p2 tried to attach on p1, p2->real_parent was pointing to already
> >> (or about to be) freed p1.
> >
> > No, p2->real_parent will be
On 10/26, Tetsuo Handa wrote:
>
> On 2018/10/26 22:04, Oleg Nesterov wrote:
> >> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
> >> when p2 tried to attach on p1, p2->real_parent was pointing to already
> >> (or about to be) freed p1.
> >
> > No, p2->real_parent will be
On 2018/10/26 22:04, Oleg Nesterov wrote:
>> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
>> when p2 tried to attach on p1, p2->real_parent was pointing to already
>> (or about to be) freed p1.
>
> No, p2->real_parent will be updated. If p1 exits it will re-parent its
>
On 2018/10/26 22:04, Oleg Nesterov wrote:
>> Suppose p1 == p2->real_parent and p2 == p3->real_parent, and p1 exited
>> when p2 tried to attach on p1, p2->real_parent was pointing to already
>> (or about to be) freed p1.
>
> No, p2->real_parent will be updated. If p1 exits it will re-parent its
>
On 10/26, Tetsuo Handa wrote:
>
> Since the "child" passed to task_is_descendant() has at least one reference
> count taken by find_get_task_by_vpid(), rcu_dereference(walker->real_parent)
> in the first iteration
>
> while (child->pid > 0) {
> if (!thread_group_leader(child))
> walker
On 10/26, Tetsuo Handa wrote:
>
> Since the "child" passed to task_is_descendant() has at least one reference
> count taken by find_get_task_by_vpid(), rcu_dereference(walker->real_parent)
> in the first iteration
>
> while (child->pid > 0) {
> if (!thread_group_leader(child))
> walker
On 2018/10/26 0:55, Oleg Nesterov wrote:
> On 10/25, Tetsuo Handa wrote:
>>
>> On 2018/10/25 21:17, Oleg Nesterov wrote:
> And yes, task_is_descendant() can hit the dead child, if nothing else it
> can
> be killed. This can explain the kasan report.
The kasan is reporting
On 2018/10/26 0:55, Oleg Nesterov wrote:
> On 10/25, Tetsuo Handa wrote:
>>
>> On 2018/10/25 21:17, Oleg Nesterov wrote:
> And yes, task_is_descendant() can hit the dead child, if nothing else it
> can
> be killed. This can explain the kasan report.
The kasan is reporting
On 10/25, Oleg Nesterov wrote:
>
> Because our rcu read-lock critical section extends beyond the return from
> synchronize_rcu(), and thus we must have a full memory barrier _between_
> that synchronize_rcu() and our rcu_read_lock(). We must see all memory
> updates,
> including thread_pid = NULL
On 10/25, Oleg Nesterov wrote:
>
> Because our rcu read-lock critical section extends beyond the return from
> synchronize_rcu(), and thus we must have a full memory barrier _between_
> that synchronize_rcu() and our rcu_read_lock(). We must see all memory
> updates,
> including thread_pid = NULL
On 10/25, Tetsuo Handa wrote:
>
> On 2018/10/25 21:17, Oleg Nesterov wrote:
> >>> And yes, task_is_descendant() can hit the dead child, if nothing else it
> >>> can
> >>> be killed. This can explain the kasan report.
> >>
> >> The kasan is reporting that child->real_parent (or maybe
> >>
On 10/25, Tetsuo Handa wrote:
>
> On 2018/10/25 21:17, Oleg Nesterov wrote:
> >>> And yes, task_is_descendant() can hit the dead child, if nothing else it
> >>> can
> >>> be killed. This can explain the kasan report.
> >>
> >> The kasan is reporting that child->real_parent (or maybe
> >>
On 2018/10/25 21:17, Oleg Nesterov wrote:
>>> And yes, task_is_descendant() can hit the dead child, if nothing else it can
>>> be killed. This can explain the kasan report.
>>
>> The kasan is reporting that child->real_parent (or maybe
>> child->real_parent->real_parent
>> or
On 2018/10/25 21:17, Oleg Nesterov wrote:
>>> And yes, task_is_descendant() can hit the dead child, if nothing else it can
>>> be killed. This can explain the kasan report.
>>
>> The kasan is reporting that child->real_parent (or maybe
>> child->real_parent->real_parent
>> or
On 10/25, Oleg Nesterov wrote:
>
> As I said below, please ignore ptracer_exception_found(), another caller for
> now,
> perhaps it needs some changes too. I even have a vague feeling that I have
> already
> blamed this function some time ago...
Heh, yes, 3 years ago ;)
On 10/25, Oleg Nesterov wrote:
>
> As I said below, please ignore ptracer_exception_found(), another caller for
> now,
> perhaps it needs some changes too. I even have a vague feeling that I have
> already
> blamed this function some time ago...
Heh, yes, 3 years ago ;)
On 10/25, Tetsuo Handa wrote:
>
> On 2018/10/25 20:13, Oleg Nesterov wrote:
> >
> > So again, suppose that "child" is already dead. Its task_struct can't be
> > freed,
> > but child->real_parent can point to the already freed memory.
>
> Yes.
>
> But if child->real_parent is pointing to the
On 10/25, Tetsuo Handa wrote:
>
> On 2018/10/25 20:13, Oleg Nesterov wrote:
> >
> > So again, suppose that "child" is already dead. Its task_struct can't be
> > freed,
> > but child->real_parent can point to the already freed memory.
>
> Yes.
>
> But if child->real_parent is pointing to the
On 10/25, Kees Cook wrote:
>
> On Thu, Oct 25, 2018 at 12:13 PM, Oleg Nesterov wrote:
> > So again, suppose that "child" is already dead. Its task_struct can't be
> > freed,
> > but child->real_parent can point to the already freed memory.
>
> I can't find a path for "child" to be released. I
On 10/25, Kees Cook wrote:
>
> On Thu, Oct 25, 2018 at 12:13 PM, Oleg Nesterov wrote:
> > So again, suppose that "child" is already dead. Its task_struct can't be
> > freed,
> > but child->real_parent can point to the already freed memory.
>
> I can't find a path for "child" to be released. I
On 10/25, Kees Cook wrote:
>
> task_is_descendant() is called under rcu_read_lock() in both
> ptracer_exception_found() and yama_ptrace_access_check() so I don't
> understand how any of the tasks could get freed? This is walking
> group_leader and real_parent -- are these not stable under
On 10/25, Kees Cook wrote:
>
> task_is_descendant() is called under rcu_read_lock() in both
> ptracer_exception_found() and yama_ptrace_access_check() so I don't
> understand how any of the tasks could get freed? This is walking
> group_leader and real_parent -- are these not stable under
On 2018/10/25 20:13, Oleg Nesterov wrote:
> On 10/25, Tetsuo Handa wrote:
>>
>> Oleg Nesterov wrote:
>>> On 10/22, Tetsuo Handa wrote:
> And again, I do not know how/if yama ensures that child is rcu-protected,
> perhaps
> task_is_descendant() needs to check pid_alive(child) right
On 2018/10/25 20:13, Oleg Nesterov wrote:
> On 10/25, Tetsuo Handa wrote:
>>
>> Oleg Nesterov wrote:
>>> On 10/22, Tetsuo Handa wrote:
> And again, I do not know how/if yama ensures that child is rcu-protected,
> perhaps
> task_is_descendant() needs to check pid_alive(child) right
On Thu, Oct 25, 2018 at 12:13 PM, Oleg Nesterov wrote:
> So again, suppose that "child" is already dead. Its task_struct can't be
> freed,
> but child->real_parent can point to the already freed memory.
I can't find a path for "child" to be released. I see task_lock()
always called on it before
On Thu, Oct 25, 2018 at 12:13 PM, Oleg Nesterov wrote:
> So again, suppose that "child" is already dead. Its task_struct can't be
> freed,
> but child->real_parent can point to the already freed memory.
I can't find a path for "child" to be released. I see task_lock()
always called on it before
On 10/25, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> > On 10/22, Tetsuo Handa wrote:
> > > > And again, I do not know how/if yama ensures that child is
> > > > rcu-protected, perhaps
> > > > task_is_descendant() needs to check pid_alive(child) right after
> > > > rcu_read_lock() ?
> > >
> >
On 10/25, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> > On 10/22, Tetsuo Handa wrote:
> > > > And again, I do not know how/if yama ensures that child is
> > > > rcu-protected, perhaps
> > > > task_is_descendant() needs to check pid_alive(child) right after
> > > > rcu_read_lock() ?
> > >
> >
On Mon, Oct 22, 2018 at 10:54 AM, Oleg Nesterov wrote:
> On 10/21, Tetsuo Handa wrote:
>>
>> On 2018/10/21 16:10, syzbot wrote:
>> > BUG: KASAN: use-after-free in __read_once_size
>> > include/linux/compiler.h:188 [inline]
>> > BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
On Mon, Oct 22, 2018 at 10:54 AM, Oleg Nesterov wrote:
> On 10/21, Tetsuo Handa wrote:
>>
>> On 2018/10/21 16:10, syzbot wrote:
>> > BUG: KASAN: use-after-free in __read_once_size
>> > include/linux/compiler.h:188 [inline]
>> > BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
Oleg Nesterov wrote:
> On 10/22, Tetsuo Handa wrote:
> > > And again, I do not know how/if yama ensures that child is rcu-protected,
> > > perhaps
> > > task_is_descendant() needs to check pid_alive(child) right after
> > > rcu_read_lock() ?
> >
> > Since the caller (ptrace() path) called
Oleg Nesterov wrote:
> On 10/22, Tetsuo Handa wrote:
> > > And again, I do not know how/if yama ensures that child is rcu-protected,
> > > perhaps
> > > task_is_descendant() needs to check pid_alive(child) right after
> > > rcu_read_lock() ?
> >
> > Since the caller (ptrace() path) called
On 10/22, Tetsuo Handa wrote:
>
> > However, task_is_descendant() looks unnecessarily complicated, it could be
> >
> > static int task_is_descendant(struct task_struct *parent,
> > struct task_struct *child)
> > {
> > int rc = 0;
> >
On 10/22, Tetsuo Handa wrote:
>
> > However, task_is_descendant() looks unnecessarily complicated, it could be
> >
> > static int task_is_descendant(struct task_struct *parent,
> > struct task_struct *child)
> > {
> > int rc = 0;
> >
On 2018/10/22 18:54, Oleg Nesterov wrote:
> On 10/21, Tetsuo Handa wrote:
>>
>> On 2018/10/21 16:10, syzbot wrote:
>>> BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188
>>> [inline]
>>> BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
>>>
On 2018/10/22 18:54, Oleg Nesterov wrote:
> On 10/21, Tetsuo Handa wrote:
>>
>> On 2018/10/21 16:10, syzbot wrote:
>>> BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188
>>> [inline]
>>> BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
>>>
On 10/21, Tetsuo Handa wrote:
>
> On 2018/10/21 16:10, syzbot wrote:
> > BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188
> > [inline]
> > BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
> > security/yama/yama_lsm.c:295
> > Read of size 8 at addr
On 10/21, Tetsuo Handa wrote:
>
> On 2018/10/21 16:10, syzbot wrote:
> > BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188
> > [inline]
> > BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
> > security/yama/yama_lsm.c:295
> > Read of size 8 at addr
On 2018/10/21 16:10, syzbot wrote:
> BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188
> [inline]
> BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
> security/yama/yama_lsm.c:295
> Read of size 8 at addr 8801c4666b20 by task syz-executor3/12722
>
On 2018/10/21 16:10, syzbot wrote:
> BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188
> [inline]
> BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
> security/yama/yama_lsm.c:295
> Read of size 8 at addr 8801c4666b20 by task syz-executor3/12722
>
52 matches
Mail list logo
