Re: lsipc(1) triggers general protection fault in sysvipc_shm_proc_show() on v4.13-rc2+

[Dominik Brodowski]

Kees,

thanks for taking a look at this!

On Sun, Jul 30, 2017 at 10:47:21AM -0700, Kees Cook wrote:
> On Sun, Jul 30, 2017 at 9:28 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> > On Sun, Jul 30, 2017 at 3:10 AM, Dominik Brodowski
> > <linux@xxxxxxxxxxxxxxxxxxxx> 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

I've bisected it to between v4.13-rc1 and 96080f697786 so far, ~7 more
kernels/reboots to go. That leaves no code changes to ipc/, but some
randstruct changes ( I have set CONFIG_GCC_PLUGIN_RANDSTRUCT=y ) which
touch some ipc-related code.

And since you asked: When I triggered the general protection fault, no
NULL pointer message or other notable line was printed out in dmesg.
When testing 96080f697786, I triggered a NULL pointer as well, but no
general protection fault.

Best,
	Dominik