linux-kernel - NULL ptr deref in wq_worker

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-next>] [day] [month] [year] [list]

Message-ID: <20190719135352.GF4240@sasha-vm>
Date:   Fri, 19 Jul 2019 09:53:52 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     tglx@...utronix.de, bigeasy@...utronix.de, peterz@...radead.org,
        mingo@...nel.org, tj@...nel.org, jiangshanlai@...il.com
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: NULL ptr deref in wq_worker_sleeping on 4.19

Hi folks,

We're seeing a rare panic on boot in wq_worker_sleeping() on boot in
4.19 kernels. I wasn't able to reproduce this with 5.2, but I'm not sure
whether it's because the issue is fixed, or I was just unlucky.

The panic looks like this:

[    0.852791] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[    0.853260] PGD 0 P4D 0 
[    0.853260] Oops: 0000 [#1] SMP PTI
[    0.853260] CPU: 7 PID: 49 Comm:  Not tainted 4.19.52-9858d02fd940 #1
[    0.853260] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007  06/02/2017
[    0.853260] RIP: 0010:kthread_data+0x12/0x30
[    0.853260] Code: 83 7f 58 00 74 02 0f 0b e9 bb 2d 19 00 0f 0b eb e2 0f 1f 80 00 00 00 00 0f 1f 44 00 00 f6 47 26 20 74 0c 48 8b 87 98 05 00 00 <48> 8b 40 10 c3 0f 0b 48 8b 87 98 05 00 00 48 8b 40 10 c3 90 66 2e
[    0.853260] RSP: 0000:ffffc900036abe38 EFLAGS: 00010002
[    0.853260] RAX: 0000000000000000 RBX: ffff8887bfbe17c0 RCX: 0000000000000000
[    0.853260] RDX: 0000000000000001 RSI: 000000000000000a RDI: ffff8887bbb4bb00
[    0.853260] RBP: ffffc900036abea0 R08: 0000000000000000 R09: 0000000000000000
[    0.853260] R10: ffffc9000368bd90 R11: 0000000000000000 R12: ffff8887bbb4bb00
[    0.853260] R13: 0000000000000000 R14: ffffc900036abe60 R15: 0000000000000000
[    0.853260] FS:  0000000000000000(0000) GS:ffff8887bfbc0000(0000) knlGS:0000000000000000
[    0.853260] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.853260] CR2: 0000000000000068 CR3: 00000007df40a000 CR4: 00000000001406e0
[    0.853260] Call Trace:
[    0.853260]  wq_worker_sleeping+0xa/0x60
[    0.853260]  __schedule+0x571/0x8c0
[    0.853260]  schedule+0x32/0x80
[    0.853260]  worker_thread+0xc7/0x440
[    0.853260]  kthread+0xf8/0x130
[    0.853260]  ret_from_fork+0x35/0x40
[    0.853260] Modules linked in:
[    0.853260] CR2: 0000000000000010
[    0.853260] ---[ end trace 160fda44361ab977 ]---

I see that this area was recently touched by 6d25be5782e4 ("sched/core,
workqueues: Distangle worker accounting from rq lock") but I'm not sure
if it's related.

--
Thanks,
Sasha