Re: [RFC PATCH] mm, oom: fix use-after-free in oom_kill_process

2019-01-21 Thread Michal Hocko
On Sat 19-01-19 08:09:34, Michal Hocko wrote: [...] > Fixes: 5e9d834a0e0c ("oom: sacrifice child with highest badness score for > parent") So I've double checked and I was wrong blaming this commit. Back then it was tasklist_lock to protect us from releasing the task. It's been only since

Re: [RFC PATCH] mm, oom: fix use-after-free in oom_kill_process

2019-01-20 Thread Shakeel Butt
On Fri, Jan 18, 2019 at 5:58 PM Roman Gushchin wrote: > > Hi Shakeel! > > > > > On looking further it seems like the process selected to be oom-killed > > has exited even before reaching read_lock(_lock) in > > oom_kill_process(). More specifically the tsk->usage is 1 which is due > > to

Re: [RFC PATCH] mm, oom: fix use-after-free in oom_kill_process

2019-01-20 Thread Shakeel Butt
On Fri, Jan 18, 2019 at 11:09 PM Michal Hocko wrote: > > On Fri 18-01-19 16:50:22, Shakeel Butt wrote: > [...] > > On looking further it seems like the process selected to be oom-killed > > has exited even before reaching read_lock(_lock) in > > oom_kill_process(). More specifically the

Re: [RFC PATCH] mm, oom: fix use-after-free in oom_kill_process

2019-01-20 Thread Shakeel Butt
On Fri, Jan 18, 2019 at 7:35 PM Tetsuo Handa wrote: > > On 2019/01/19 9:50, Shakeel Butt wrote: > > On looking further it seems like the process selected to be oom-killed > > has exited even before reaching read_lock(_lock) in > > oom_kill_process(). More specifically the tsk->usage is 1 which is

Re: [RFC PATCH] mm, oom: fix use-after-free in oom_kill_process

2019-01-18 Thread Michal Hocko
On Fri 18-01-19 16:50:22, Shakeel Butt wrote: [...] > On looking further it seems like the process selected to be oom-killed > has exited even before reaching read_lock(_lock) in > oom_kill_process(). More specifically the tsk->usage is 1 which is due > to get_task_struct() in oom_evaluate_task()

Re: [RFC PATCH] mm, oom: fix use-after-free in oom_kill_process

2019-01-18 Thread Tetsuo Handa
On 2019/01/19 9:50, Shakeel Butt wrote: > On looking further it seems like the process selected to be oom-killed > has exited even before reaching read_lock(_lock) in > oom_kill_process(). More specifically the tsk->usage is 1 which is due > to get_task_struct() in oom_evaluate_task() and the

Re: [RFC PATCH] mm, oom: fix use-after-free in oom_kill_process

2019-01-18 Thread Roman Gushchin
Hi Shakeel! > > On looking further it seems like the process selected to be oom-killed > has exited even before reaching read_lock(_lock) in > oom_kill_process(). More specifically the tsk->usage is 1 which is due > to get_task_struct() in oom_evaluate_task() and the put_task_struct > within

[RFC PATCH] mm, oom: fix use-after-free in oom_kill_process

2019-01-18 Thread Shakeel Butt
In our internal syzbot instance running on upstream kernel, we see the following crash. syzbot has found the following crash on: HEAD commit: 47bfa6d9dc8c Merge tag 'selinux-pr-20190115' of git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: