linux-kernel - Re: lsipc(1) triggers general protection fault in sysvipc_shm_proc

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jKpua12WdS1ovhgGWS7T-Mdk2OSovteJGiw0JOe=xxSPA@mail.gmail.com>
Date:   Sun, 30 Jul 2017 10:47:21 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     Manfred Spraul <manfred@...orfullife.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: lsipc(1) triggers general protection fault in sysvipc_shm_proc_show()
 on v4.13-rc2+

On Sun, Jul 30, 2017 at 9:28 AM, Kees Cook <keescook@...omium.org> wrote:
> On Sun, Jul 30, 2017 at 3:10 AM, Dominik Brodowski
> <linux@...inikbrodowski.net> wrote:
>> Kees, Manfred,
>>
>> on Linus' most recent kernel (v4.13-rc2+, git head 0a07b238e5f48), lsipc(1)
>> works as expected in initramfs and before gnome starts up. Afterwards,
>> running lsipc as user(!) results in the following general protection fault
>> and a quite unusable system:
>>
>> [  183.018415] general protection fault: 0000 [#1] PREEMPT SMP
>> [  183.018486] Modules linked in:
>> [  183.018521] CPU: 2 PID: 1964 Comm: lsipc Not tainted 4.13.0-rc2+ #2
>> [  183.018575] Hardware name: Dell Inc. XPS 13 9343/0TM99H, BIOS A11 12/08/2016
>> [  183.018636] task: ffff9f0651708000 task.stack: ffffa8d3837d0000
>> [  183.018692] RIP: 0010:shm_add_rss_swap.isra.1+0x13/0xa0
>> [  183.018738] RSP: 0018:ffffa8d3837d3d78 EFLAGS: 00010246
>> [  183.018785] RAX: 6b6b6b6b6b6b6b6b RBX: ffff9f065c29cc70 RCX: 0000000000000000
>> [  183.018845] RDX: ffffa8d3837d3de0 RSI: ffffa8d3837d3dd8 RDI: ffff9f065c29cd50
>> [  183.018905] RBP: ffffa8d3837d3d98 R08: 0000000000000000 R09: ffff9f065c29cc70
>> [  183.018965] R10: 0000000000000040 R11: 0000000000000000 R12: ffffffff8bc5b9a0
>> [  183.019026] R13: ffff9f063838a280 R14: ffff9f065c29cc70 R15: ffff9f068bcecaa0
>> [  183.019088] FS:  00007cec9dce2700(0000) GS:ffff9f069f500000(0000) knlGS:0000000000000000
>> [  183.019156] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [  183.019206] CR2: 00007ffe4e7a8ff8 CR3: 000000020b9ca000 CR4: 00000000003406e0
>> [  183.019265] Call Trace:
>> [  183.019294]  sysvipc_shm_proc_show+0x5e/0x150
>> [  183.019338]  ? _raw_spin_lock+0x17/0x40
>> [  183.019376]  ? sysvipc_find_ipc+0xbc/0xf0
>> [  183.019416]  sysvipc_proc_show+0x1a/0x30
>> [  183.019456]  seq_read+0x2e9/0x3f0
>> [  183.019492]  proc_reg_read+0x42/0x70
>> [  183.019528]  __vfs_read+0x18/0x40
>> [  183.019562]  vfs_read+0x8e/0x110
>> [  183.019595]  SyS_read+0x55/0xc0
>> [  183.019629]  entry_SYSCALL_64_fastpath+0x18/0xa8
>> [  183.019671] RIP: 0033:0x7cec9d5fcb90
>> [  183.019703] RSP: 002b:00007ffe4e7a97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
>> [  183.019769] RAX: ffffffffffffffda RBX: 000007e254b1a221 RCX: 00007cec9d5fcb90
>> [  183.019829] RDX: 0000000000000400 RSI: 000007e255712020 RDI: 0000000000000003
>> [  183.019890] RBP: 00007cec9d8ba588 R08: 0000000000000003 R09: 000000000000007c
>> [  183.019950] R10: 0000000000000040 R11: 0000000000000246 R12: 00007cec9d8b9820
>> [  183.020010] R13: 0000000000000011 R14: 00007ffe4e7a95b0 R15: 00007ffe4e7a95b0
>> [  183.020071] Code: 7f 18 48 89 e5 e8 5e ff ff ff 85 c0 75 02 5d c3 0f ff 5d c3 0f 1f 40 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 53 48 8b 07 <4c> 8b 60 08 48 8b 40 68 48 3d 80 13 47 8b 74 08 48 3d 00 15 45
>> [  183.020290] RIP: shm_add_rss_swap.isra.1+0x13/0xa0 RSP: ffffa8d3837d3d78
>> [  183.042734] ---[ end trace c5a8076d8f19909f ]---
>> [  183.042740] note: lsipc[1964] exited with preempt_count 1
>
> Can you send your config? Also, are you able to do a bisect to find
> the specific commit that is triggering this? Are there any interesting
> dmesg lines before the general protection fault line?

Ah, I have been able to reproduce this now. I'll see if I can track this down...

[   20.640404] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000088

-Kees

-- 
Kees Cook
Pixel Security