* Extra backport for 4.4.y KPTI+KASAN
@ 2018-01-05 12:11 Jamie Iles
2018-01-05 12:15 ` Jamie Iles
0 siblings, 1 reply; 3+ messages in thread
From: Jamie Iles @ 2018-01-05 12:11 UTC (permalink / raw)
To: Greg KH; +Cc: aryabinin, stable, Borislav Petkov
Hi Greg,
When booting a 4.4.y stable-rc kernel with a fairly minimal config and
CONFIG_KASAN=y and "nopti" on the kernel command line, or v4.4.109, I
get a load of KASAN spews as below. A bisect takes me back to
85d3700c744a11 (x86/mm: If INVPCID is available, use it to flush global
mappings), but I think the real fix is to also add 69e0210fd01ff15
(x86/kasan: Clear kasan_zero_page after TLB flush) onto your branch to
address these false positives.
Thanks,
Jamie
[ 4.114576] BUG: KASAN: stack-out-of-bounds in __rmqueue.isra.66+0x14b/0xb50 at addr ffffea000467fd18
[ 4.115217] Read of size 4 by task swapper/0/0
[ 4.115529] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G B 4.4.109 #77
[ 4.116038] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
[ 4.116651] 0000000000000000 ffffffff82807940 ffffffff8159a29d 0000000000000004
[ 4.117201] fffff940008cffa3 ffffffff828079c0 ffffffff812929e7 ffffffffffffffc3
[ 4.117758] 000000000467fd20 0000000000000082 ffffffff8121c87b 3634303030616566
[ 4.118318] Call Trace:
[ 4.118503] [<ffffffff8159a29d>] dump_stack+0x86/0xc9
[ 4.118866] [<ffffffff812929e7>] kasan_report+0x327/0x4f0
[ 4.119252] [<ffffffff8121c87b>] ? __rmqueue.isra.66+0x14b/0xb50
[ 4.119685] [<ffffffff81291a33>] __asan_load4+0x23/0x70
[ 4.120063] [<ffffffff8121c87b>] __rmqueue.isra.66+0x14b/0xb50
[ 4.120472] [<ffffffff8121c730>] ? split_free_page+0xa0/0xa0
[ 4.120871] [<ffffffff81291b96>] ? __asan_store8+0x26/0x70
[ 4.121272] [<ffffffff8121d708>] get_page_from_freelist+0x488/0x11b0
[ 4.121722] [<ffffffff8121f4d2>] __alloc_pages_nodemask+0x2f2/0x5e0
[ 4.122165] [<ffffffff8121f1e0>] ? __alloc_pages_slowpath.constprop.73+0xc40/0xc40
[ 4.122698] [<ffffffff815bac5b>] ? _find_next_bit+0x3b/0xa0
[ 4.123101] [<ffffffff815bad0f>] ? find_first_bit+0x1f/0x70
[ 4.123499] [<ffffffff8128280d>] alloc_page_interleave+0x5d/0xc0
[ 4.123918] [<ffffffff812831e2>] alloc_pages_current+0x1b2/0x240
[ 4.124340] [<ffffffff8126de97>] __vmalloc_node_range+0x247/0x3d0
[ 4.124777] [<ffffffff82f1d3bb>] ? alloc_large_system_hash+0x168/0x250
[ 4.125248] [<ffffffff8126e06a>] __vmalloc+0x4a/0x50
[ 4.125613] [<ffffffff82f1d3bb>] ? alloc_large_system_hash+0x168/0x250
[ 4.126065] [<ffffffff82f1d3bb>] alloc_large_system_hash+0x168/0x250
[ 4.126461] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120
[ 4.126916] [<ffffffff82f25c6e>] vfs_caches_init+0xb7/0x108
[ 4.127307] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120
[ 4.127793] [<ffffffff82eed143>] start_kernel+0x4a3/0x524
[ 4.128194] [<ffffffff82eecca0>] ? thread_info_cache_init+0x6/0x6
[ 4.128625] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120
[ 4.129086] [<ffffffff82f73577>] ? memblock_reserve+0x4a/0x4f
[ 4.129504] [<ffffffff82eec312>] x86_64_start_reservations+0x2a/0x2c
[ 4.129948] [<ffffffff82eec456>] x86_64_start_kernel+0x142/0x151
[ 4.130373] Memory state around the buggy address:
[ 4.130724] ffffea000467fc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 4.131231] ffffea000467fc80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
[ 4.131737] >ffffea000467fd00: 00 00 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
[ 4.132233] ^
[ 4.132516] ffffea000467fd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 4.133026] ffffea000467fe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Extra backport for 4.4.y KPTI+KASAN
2018-01-05 12:11 Extra backport for 4.4.y KPTI+KASAN Jamie Iles
@ 2018-01-05 12:15 ` Jamie Iles
2018-01-05 13:36 ` Greg KH
0 siblings, 1 reply; 3+ messages in thread
From: Jamie Iles @ 2018-01-05 12:15 UTC (permalink / raw)
To: gregkh; +Cc: aryabinin, stable, Borislav Petkov
Resending with Greg's correct email address.
On Fri, Jan 05, 2018 at 12:11:14PM +0000, Jamie Iles wrote:
> Hi Greg,
>
> When booting a 4.4.y stable-rc kernel with a fairly minimal config and
> CONFIG_KASAN=y and "nopti" on the kernel command line, or v4.4.109, I
> get a load of KASAN spews as below. A bisect takes me back to
> 85d3700c744a11 (x86/mm: If INVPCID is available, use it to flush global
> mappings), but I think the real fix is to also add 69e0210fd01ff15
> (x86/kasan: Clear kasan_zero_page after TLB flush) onto your branch to
> address these false positives.
>
> Thanks,
>
> Jamie
>
> [ 4.114576] BUG: KASAN: stack-out-of-bounds in __rmqueue.isra.66+0x14b/0xb50 at addr ffffea000467fd18
> [ 4.115217] Read of size 4 by task swapper/0/0
> [ 4.115529] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G B 4.4.109 #77
> [ 4.116038] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
> [ 4.116651] 0000000000000000 ffffffff82807940 ffffffff8159a29d 0000000000000004
> [ 4.117201] fffff940008cffa3 ffffffff828079c0 ffffffff812929e7 ffffffffffffffc3
> [ 4.117758] 000000000467fd20 0000000000000082 ffffffff8121c87b 3634303030616566
> [ 4.118318] Call Trace:
> [ 4.118503] [<ffffffff8159a29d>] dump_stack+0x86/0xc9
> [ 4.118866] [<ffffffff812929e7>] kasan_report+0x327/0x4f0
> [ 4.119252] [<ffffffff8121c87b>] ? __rmqueue.isra.66+0x14b/0xb50
> [ 4.119685] [<ffffffff81291a33>] __asan_load4+0x23/0x70
> [ 4.120063] [<ffffffff8121c87b>] __rmqueue.isra.66+0x14b/0xb50
> [ 4.120472] [<ffffffff8121c730>] ? split_free_page+0xa0/0xa0
> [ 4.120871] [<ffffffff81291b96>] ? __asan_store8+0x26/0x70
> [ 4.121272] [<ffffffff8121d708>] get_page_from_freelist+0x488/0x11b0
> [ 4.121722] [<ffffffff8121f4d2>] __alloc_pages_nodemask+0x2f2/0x5e0
> [ 4.122165] [<ffffffff8121f1e0>] ? __alloc_pages_slowpath.constprop.73+0xc40/0xc40
> [ 4.122698] [<ffffffff815bac5b>] ? _find_next_bit+0x3b/0xa0
> [ 4.123101] [<ffffffff815bad0f>] ? find_first_bit+0x1f/0x70
> [ 4.123499] [<ffffffff8128280d>] alloc_page_interleave+0x5d/0xc0
> [ 4.123918] [<ffffffff812831e2>] alloc_pages_current+0x1b2/0x240
> [ 4.124340] [<ffffffff8126de97>] __vmalloc_node_range+0x247/0x3d0
> [ 4.124777] [<ffffffff82f1d3bb>] ? alloc_large_system_hash+0x168/0x250
> [ 4.125248] [<ffffffff8126e06a>] __vmalloc+0x4a/0x50
> [ 4.125613] [<ffffffff82f1d3bb>] ? alloc_large_system_hash+0x168/0x250
> [ 4.126065] [<ffffffff82f1d3bb>] alloc_large_system_hash+0x168/0x250
> [ 4.126461] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120
> [ 4.126916] [<ffffffff82f25c6e>] vfs_caches_init+0xb7/0x108
> [ 4.127307] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120
> [ 4.127793] [<ffffffff82eed143>] start_kernel+0x4a3/0x524
> [ 4.128194] [<ffffffff82eecca0>] ? thread_info_cache_init+0x6/0x6
> [ 4.128625] [<ffffffff82eec120>] ? early_idt_handler_array+0x120/0x120
> [ 4.129086] [<ffffffff82f73577>] ? memblock_reserve+0x4a/0x4f
> [ 4.129504] [<ffffffff82eec312>] x86_64_start_reservations+0x2a/0x2c
> [ 4.129948] [<ffffffff82eec456>] x86_64_start_kernel+0x142/0x151
> [ 4.130373] Memory state around the buggy address:
> [ 4.130724] ffffea000467fc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 4.131231] ffffea000467fc80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
> [ 4.131737] >ffffea000467fd00: 00 00 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
> [ 4.132233] ^
> [ 4.132516] ffffea000467fd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 4.133026] ffffea000467fe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Extra backport for 4.4.y KPTI+KASAN
2018-01-05 12:15 ` Jamie Iles
@ 2018-01-05 13:36 ` Greg KH
0 siblings, 0 replies; 3+ messages in thread
From: Greg KH @ 2018-01-05 13:36 UTC (permalink / raw)
To: Jamie Iles; +Cc: aryabinin, stable, Borislav Petkov
On Fri, Jan 05, 2018 at 12:15:07PM +0000, Jamie Iles wrote:
> Resending with Greg's correct email address.
>
> On Fri, Jan 05, 2018 at 12:11:14PM +0000, Jamie Iles wrote:
> > Hi Greg,
> >
> > When booting a 4.4.y stable-rc kernel with a fairly minimal config and
> > CONFIG_KASAN=y and "nopti" on the kernel command line, or v4.4.109, I
> > get a load of KASAN spews as below. A bisect takes me back to
> > 85d3700c744a11 (x86/mm: If INVPCID is available, use it to flush global
> > mappings), but I think the real fix is to also add 69e0210fd01ff15
> > (x86/kasan: Clear kasan_zero_page after TLB flush) onto your branch to
> > address these false positives.
Again, nice find! I've queued this up as well, thanks.
greg k-h
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-01-05 13:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-05 12:11 Extra backport for 4.4.y KPTI+KASAN Jamie Iles
2018-01-05 12:15 ` Jamie Iles
2018-01-05 13:36 ` Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.