After having fixed a NULL pointer dereference in SCTP 1abd165e (net:
sctp: fix NULL pointer dereference in socket destruction), I ran into
the following NULL pointer dereference in the crypto subsystem with
the same reproducer, easily hit each time:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [81070321] __wake_up_common+0x31/0x90
PGD 0
Oops: [#1] SMP
Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..]
CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF3.10.0-rc5+ #1
Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
task: 88007b6cf4e0 ti: 88007b7cc000 task.ti: 88007b7cc000
RIP: 0010:[81070321] [81070321] __wake_up_common+0x31/0x90
RSP: 0018:88007b7cde08 EFLAGS: 00010082
RAX: ffe8 RBX: 88003756c130 RCX:
RDX: RSI: 0003 RDI: 88003756c130
RBP: 88007b7cde48 R08: R09: 88012b173200
R10: R11: R12: 0282
R13: 88003756c138 R14: R15:
FS: () GS:88012fc6() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: CR3: 01a0b000 CR4: 07e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Stack:
88007b7cde28 0003 88007b7cde28 88003756c130
0282 88003756c128 81227670
88007b7cde78 810722b7 88007cdcf000 81a90540
Call Trace:
[81227670] ? crypto_alloc_pcomp+0x20/0x20
[810722b7] complete_all+0x47/0x60
[81227708] cryptomgr_probe+0x98/0xc0
[81227670] ? crypto_alloc_pcomp+0x20/0x20
[8106760e] kthread+0xce/0xe0
[81067540] ? kthread_freezable_should_stop+0x70/0x70
[815450dc] ret_from_fork+0x7c/0xb0
[81067540] ? kthread_freezable_should_stop+0x70/0x70
Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8
4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e
RIP [81070321] __wake_up_common+0x31/0x90
RSP 88007b7cde08
CR2:
---[ end trace b495b19270a4d37e ]---
My assumption is that the following is happening: the minimal SCTP
tool runs under ``echo 1 /proc/sys/net/sctp/auth_enable'', hence
it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs().
It forks itself, heavily allocates, binds, listens and waits in
accept on sctp sockets, and then randomly kills some of them (no
need for an actual client in this case to hit this). Then, again,
allocating, binding, etc, and then killing child processes.
The problem that might be happening here is that cryptomgr requests
the module to probe/load through cryptomgr_schedule_probe(), but
before the thread handler cryptomgr_probe() returns, we return from
the wait_for_completion_interruptible() function and probably already
have cleared up larval, thus we run into a NULL pointer dereference
when in cryptomgr_probe() complete_all() is being called.
If we wait with wait_for_completion() instead, this panic will not
occur anymore.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
---
I'm not very familiar with the crypto subsystem and not entirely
sure if this is the best solution. However, it has fixed the panic
in my case.
crypto/algboss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/algboss.c b/crypto/algboss.c
index 769219b..eee89a5 100644
--- a/crypto/algboss.c
+++ b/crypto/algboss.c
@@ -195,7 +195,7 @@ static int cryptomgr_schedule_probe(struct crypto_larval
*larval)
if (IS_ERR(thread))
goto err_free_param;
- wait_for_completion_interruptible(larval-completion);
+ wait_for_completion(larval-completion);
return NOTIFY_STOP;
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
