Oh, yes, the patch 39af176 has been skip the kthread
on mm_update_next_owner .
Thanks for your tips.

thanks and regards


Michal Hocko <mhocko@kernel.org> 于2018年12月18日周二 下午5:52写道：

> On Tue 18-12-18 13:24:44, gchen.guomin@gmail.com wrote:
> > From: guomin chen <gchen.guomin@gmail.com>
> >
> > When mm->owner is modified by exit_mm, if the new owner directly calls
> > unuse_mm to exit, it will cause Use-After-Free. Due to the unuse_mm()
> > directly sets tsk->mm=NULL.
> >
> >  Under normal circumstances,When do_exit exits, mm->owner will
> >  be updated on exit_mm(). but when the kernel process calls
> >  unuse_mm() and then exits,mm->owner cannot be updated. And it
> >  will point to a task that has been released.
> >
> > The current issue flow is as follows: (Process A,B,C use the same mm)
> > Process C              Process A         Process B
> > qemu-system-x86_64:     kernel:vhost_net  kernel: vhost_net
> > open /dev/vhost-net
> >   VHOST_SET_OWNER   create kthread vhost-%d  create kthread vhost-%d
> >   network init           use_mm()          use_mm()
> >    ...                   ...
> >    Abnormal exited
> >    ...
> >   do_exit
> >   exit_mm()
> >   update mm->owner to A
> >   exit_files()
> >    close_files()
> >    kthread_should_stop() unuse_mm()
> >     Stop Process A       tsk->mm=NULL
> >                          do_exit()
> >                          can't update owner
> >                          A exit completed  vhost-%d  rcv first package
> >                                            vhost-%d build rcv buffer for
> vq
> >                                            page fault
> >                                            access mm & mm->owner
> >                                            NOW,mm->owner still pointer A
> >                                            kernel UAF
> >     stop Process B
> >
> > Although I am having this issue on vhost_net,But it affects all users of
> > unuse_mm.
>
> I am confused. How can we ever assign the owner to a kernel thread. We
> skip those explicitly. It simply doesn't make any sense to have an owner
> a kernel thread.
> --
> Michal Hocko
> SUSE Labs
>