lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 21 Aug 2018 11:37:03 -0700
From:   Yang Shi <yang.shi@...ux.alibaba.com>
To:     gregkh@...uxfoundation.org, ak@...ux.intel.com, tglx@...utronix.de,
        dave.hansen@...el.com, dwmw@...zon.co.uk
Cc:     stable@...r.kernel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, YangShi <yang.shi@...ux.alibaba.com>
Subject: [BUG] madvise05 leads kernel panic on 4.9.122

Hi folks,


I just ran some regression test on stable 4.9.122 with LTP. madvise05 
triggers the below kernel panic:


[ 6785.089994] BUG: unable to handle kernel paging request at 
ffffeaff44488020
[ 6785.097952] IP: [] page_remove_rmap+0x27/0x580
[ 6785.104810] PGD 0
[ 6785.106859]
[ 6785.108526] Oops: 0000 [#1] SMP
[ 6785.112029] Modules linked in: mptctl(E) mptbase(E) tun(E) fuse(E) 
vfat(E) fat(E) btrfs(E) xor(E) raid6_pq(E) xfs(E)
[ 6785.123905] CPU: 14 PID: 77983 Comm: madvise05 Tainted: G E 
4.9.122-001.ali3000_nightly_cov_20180820_193.test.alios7.x86_64 #1
[ 6785.137880] Hardware name: Dell Inc. PowerEdge R720xd/0X6FFV, BIOS 
1.3.6 09/11/2012
[ 6785.146425] task: ffff882daeb78000 task.stack: ffffc9001b438000
[ 6785.153031] RIP: 0010:[] [] page_remove_rmap+0x27/0x580
[ 6785.162461] RSP: 0018:ffffc9001b43bc50 EFLAGS: 00010246
[ 6785.168388] RAX: 0000000000000000 RBX: ffffeaff44488000 RCX: 
0000000000000080
[ 6785.176351] RDX: ffffeaff44488000 RSI: 0000000000000001 RDI: 
ffffeaff44488000
[ 6785.184315] RBP: ffffc9001b43bc80 R08: ffff882f9d4a6540 R09: 
ffffffff84bcdf60
[ 6785.192277] R10: 0000000000000000 R11: 0000000000000000 R12: 
0000000000000001
[ 6785.200241] R13: ffff882db6996910 R14: ffffea00b6da65b0 R15: 
00003fffffe00000
[ 6785.208205] FS: 00002ae5a3dfbb80(0000) GS:ffff882fbf180000(0000) 
knlGS:0000000000000000
[ 6785.217234] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6785.223646] CR2: ffffeaff44488020 CR3: 0000002f9d51c000 CR4: 
00000000000606f0
[ 6785.231610] Stack:
[ 6785.233851] 0000000000000000 00003ffffd6b3320 0434f9415ac47f2c 
ffffeaff44488000
[ 6785.242143] ffffc9001b43bdd8 ffff882db6996910 ffffc9001b43bcc0 
ffffffff81355aaa
[ 6785.250438] ffff882f9d4a6540 00002ae5a4400000 00002ae5a4600000 
ffffffff84bcd7a0
[ 6785.258728] Call Trace:
[ 6785.261460] [] zap_huge_pmd+0x28a/0x640
[ 6785.267585] [] unmap_page_range+0x532/0x630
[ 6785.274087] [] unmap_single_vma+0xa9/0x160
[ 6785.280501] [] unmap_vmas+0x5f/0xe0
[ 6785.286236] [] unmap_region+0xe4/0x1e0
[ 6785.292263] [] ? blk_finish_plug+0x3c/0x60
[ 6785.298669] [] ? SYSC_madvise+0x69b/0xed0
[ 6785.304985] [] do_munmap+0x39b/0x5b0
[ 6785.310818] [] SyS_munmap+0x78/0xb0
[ 6785.316552] [] do_syscall_64+0xf4/0x350
[ 6785.322676] [] entry_SYSCALL_64_after_swapgs+0x58/0xca
[ 6785.330244] Code: 00 00 00 00 66 66 66 66 90 55 <48> 8b 57 20 48 89 
f8 f6 c2 01 0f
[ 6785.339011] RIP [] page_remove_rmap+0x27/0x580
[ 6785.345825] RSP
[ 6785.349715] CR2: ffffeaff44488020


The same test case works well on both 4.9.119 and the latest Linus's 
tree. So, it looks it is caused by the L1TF patches on the stable tree.


And, the madvise05 test case can be simplified to the below test program:


#include <sys/mman.h>
#include <stdio.h>

void main()
{
         void *addr;
         int err;

         addr = mmap(NULL, 32 * 1024 * 1024, PROT_READ,
                     MAP_PRIVATE | MAP_ANONYMOUS | MAP_POPULATE, -1, 0);

         if (addr == MAP_FAILED) {
                 printf("mmap failed\n");
                 return;
         }

         err = mprotect(addr, 32 * 1024 * 1024, PROT_NONE);
         if (err < 0) {
                 printf("mprotect failed\n");
                 return;
         }

         munmap(addr, 32 * 1024 * 1024);
}


You may be already aware of this problem or any hint is appreciated.


Thanks,

Yang

Powered by blists - more mailing lists