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

[William Breathitt Gray]

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.

The dereference address is the value you write to
`/proc/sys/vm/nr_hugepages`. When you write the value 0, this becomes a
NULL pointer and an obvious oops condition; but other values might end
up just globbering memory and not actually cause an oops:
https://lkml.org/lkml/2020/8/25/1324

What's the non-zero value you used to test?

William Breathitt Gray

> 
> > 
> > [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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20200929/569b4088/attachment.sig>