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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 09 Jan 2019 10:44:27 +0100
From:   Christian Brauner <christian@...uner.io>
To:     kernel test robot <rong.a.chen@...el.com>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Martijn Coenen <maco@...roid.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Todd Kjos <tkjos@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>, lkp@...org
Subject: Re: [LKP] [binder] 3ad20fe393: BUG:unable_to_handle_kernel

On January 9, 2019 9:50:41 AM GMT+01:00, kernel test robot <rong.a.chen@...el.com> wrote:
>FYI, we noticed the following commit (built with gcc-7):
>
>commit: 3ad20fe393b31025bebfc2d76964561f65df48aa ("binder: implement
>binderfs")
>https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
>in testcase: trinity
>with following parameters:
>
>	runtime: 300s
>
>test-description: Trinity is a linux system call fuzz tester.
>test-url: http://codemonkey.org.uk/projects/trinity/
>
>
>on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2
>-m 768M
>
>caused below changes (please refer to attached dmesg/kmsg for entire
>log/backtrace):
>
>
>+------------------------------------------+------------+------------+
>|                                          | 80cd795630 | 3ad20fe393 |
>+------------------------------------------+------------+------------+
>| boot_successes                           | 17         | 1          |
>| boot_failures                            | 8          | 31         |
>| invoked_oom-killer:gfp_mask=0x           | 6          |            |
>| Mem-Info                                 | 6          |            |
>| BUG:kernel_in_stage                      | 2          | 4          |
>| RIP:__put_user_8                         | 1          |            |
>| BUG:unable_to_handle_kernel              | 0          | 27         |
>| Oops:#[##]                               | 0          | 27         |
>| RIP:binderfs_mount                       | 0          | 27         |
>| Kernel_panic-not_syncing:Fatal_exception | 0          | 27         |
>+------------------------------------------+------------+------------+
>
>
>
>[    8.360965] BUG: unable to handle kernel NULL pointer dereference at
>00000000000006a0
>[    8.362067] PGD 0 P4D 0 
>[    8.362437] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
>[    8.363131] CPU: 0 PID: 1 Comm: swapper Not tainted
>4.20.0-rc6-00107-g3ad20fe #2
>[    8.364177] RIP: 0010:binderfs_mount+0x42/0x480
>[    8.364820] Code: 89 fc 49 c7 c7 ff ff ff ff 48 83 ec 20 e8 86 5d 86
>ff 48 8b 04 25 40 10 e3 ab 48 8b 80 28 06 00 00 be 15 00 00 00 48 8b 58
>10 <48> 8b bb a0 06 00 00 e8 e2 3c 7d ff 84 c0 75 19 e8 59 5d 86 ff 48
>[    8.367104] RSP: 0000:ffffb6a78000bd98 EFLAGS: 00010293
>[    8.367104] RAX: ffffffffabe48e40 RBX: 0000000000000000 RCX:
>ffffffffab2bfd6a
>[    8.367104] RDX: 0000000000000000 RSI: 0000000000000015 RDI:
>ffffffffabf38d60
>[    8.367104] RBP: ffffb6a78000bde8 R08: 0000000000000000 R09:
>0000000000000000
>[    8.367104] R10: 0000000000000000 R11: ffff90c7ec4f2980 R12:
>ffffffffabf38d60
>[    8.367104] R13: 0000000000400000 R14: ffffffffabf38d60 R15:
>ffffffffffffffff
>[    8.367104] FS:  0000000000000000(0000) GS:ffffffffabe2d000(0000)
>knlGS:0000000000000000
>[    8.367104] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[    8.367104] CR2: 00000000000006a0 CR3: 0000000027e19000 CR4:
>00000000000406b0
>[    8.367104] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>0000000000000000
>[    8.367104] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
>0000000000000400
>[    8.367104] Call Trace:
>[    8.367104]  ? __lockdep_init_map+0x4d/0x1b0
>[    8.367104]  mount_fs+0x30/0xe0
>[    8.367104]  vfs_kern_mount+0x63/0x160

Thanks. A fix for this is already in Greg's char-misc tree queued up for -rc2.
The wrong kern_mount() call is gone then.

Christian

Powered by blists - more mailing lists