ACK: [SRU][CVE-2020-25285][BIONIC][PATCH 0/1] mm/hugetlb: fix a race between hugetlb sysctl handlers

[Thadeu Lima de Souza Cascardo]

On Tue, Sep 29, 2020 at 12:52:17PM -0400, William Breathitt Gray wrote:
> On Tue, Sep 29, 2020 at 08:24:03AM -0300, Thadeu Lima de Souza Cascardo wrote:
> > On Mon, Sep 28, 2020 at 03:08:01PM -0400, William Breathitt Gray wrote:
> > > SRU Justification
> > > =================
> > > 
> > > [Impact]
> > > 
> > > A race condition between hugetlb sysctl handlers in mm/hugetlb.c in the
> > > Linux kernel before 5.8.8 could be used by local attackers to corrupt
> > > memory, cause a NULL pointer dereference, or possibly have unspecified
> > > other impact, aka CID-17743798d812.
> > > 
> > > [Testing]
> > > 
> > > The following oops was seen:
> > > 
> > >     BUG: kernel NULL pointer dereference, address: 0000000000000000
> > >     #PF: supervisor instruction fetch in kernel mode
> > >     #PF: error_code(0x0010) - not-present page
> > >     Code: Bad RIP value.
> > >     ...
> > >     Call Trace:
> > >      ? set_max_huge_pages+0x3da/0x4f0
> > >      ? alloc_pool_huge_page+0x150/0x150
> > >      ? proc_doulongvec_minmax+0x46/0x60
> > >      ? hugetlb_sysctl_handler_common+0x1c7/0x200
> > >      ? nr_hugepages_store+0x20/0x20
> > >      ? copy_fd_bitmaps+0x170/0x170
> > >      ? hugetlb_sysctl_handler+0x1e/0x20
> > >      ? proc_sys_call_handler+0x2f1/0x300
> > >      ? unregister_sysctl_table+0xb0/0xb0
> > >      ? __fd_install+0x78/0x100
> > >      ? proc_sys_write+0x14/0x20
> > >      ? __vfs_write+0x4d/0x90
> > >      ? vfs_write+0xef/0x240
> > >      ? ksys_write+0xc0/0x160
> > >      ? __ia32_sys_read+0x50/0x50
> > >      ? __close_fd+0x129/0x150
> > >      ? __x64_sys_write+0x43/0x50
> > >      ? do_syscall_64+0x6c/0x200
> > >      ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > 
> > > Upstream discussions suggests a simple way to reproduce the error: let
> > > more than one thread write to `/proc/sys/vm/nr_hugepages` -- this should
> > > trigger the race condition and eventually result in the kernel oops.
> > > 
> > > See <https://lkml.org/lkml/2020/8/24/2104> for reference.
> > 
> > I can easily reproduce a crash when doing just what is told here, that is, have
> > two processes writing 0 to /proc/sys/vm/nr_hugepages. It doesn't take long to
> > have such a race condition. Reproduced it twice. When using a value other than
> > 0, it didn't crash after hours.
> > 
> > Was the patch tested against such a reproducer?
> > 
> > Cascardo.
> 
> Just a follow-up: I was able to reproduce the race condition issue as
> well by writing 0 to /proc/sys/vm/nr_hugepages using several thread.
> Once this patch is applied to fix the bug, I am no longer able to
> reproduce.
> 
> William Breathitt Gray
> 

That's great! Thanks a lot for following this up.

Acked-by: Thadeu Lima de Souza Cascardo <cascardo at canonical.com>

> > > 
> > > [Regression Potential]
> > > 
> > > Regression potential should be low. This fix is a simple backport of the
> > > upstream patch, and it's the same that has already been merged in Focal
> > > and Xenial.
> > > 
> > > [Miscellaneous]
> > > 
> > > This bug fix has already been merged in Focal (commit 5f84359e290f) and
> > > Xenial (commit 9e8fee58b064).
> > > 
> > > Muchun Song (1):
> > >   mm/hugetlb: fix a race between hugetlb sysctl handlers
> > > 
> > >  mm/hugetlb.c | 26 ++++++++++++++++++++------
> > >  1 file changed, 20 insertions(+), 6 deletions(-)
> > > 
> > > -- 
> > > 2.25.1
> > > 
> > > 
> > > -- 
> > > kernel-team mailing list
> > > kernel-team at lists.ubuntu.com
> > > https://lists.ubuntu.com/mailman/listinfo/kernel-team