Bug #2702
closedReading from /dev/random causes kernel panic
Description
- dd if=/dev/random of=/dev/null bs=1 count=1
panic with 1 spinlocks held
panic: assertion "state->reseed_cnt > 0" failed in csprng_get_random at /usr/src/sys/kern/subr_csprng.c:150
cpuid = 0
Trace beginning at frame 0xffffffe043d1b5d8
?|.() at ?|.+0x21f 0xffffffff805e4340
?|.() at ?|.+0x21f 0xffffffff805e4340
() at +0xd8 0xffffffff8060e250
() at +0xe8 0xffffffff805dd575
() at +0x1f5 0xffffffff805e80cc
?$() at ?$+0x14 0xffffffff805e833a
#,() at >#,+0x7d 0xffffffff805c1a31
???F ?F$?() at ???F ?F$?+0x178 0xffffffff807d6850
?H?????1() at ?H?????1+0x183 0xffffffff8061e539
D??H T???() at D??H T???+0x66 0xffffffff8061e8cc
???() at ??
?+0x3fb 0xffffffff809c3162
?() at ?+0xcb 0xffffffff809abdab
Debugger("panic")
CPU0 stopping CPUs: 0x00000000
stopped
Stopped at +0x38: movb $0,0x12b6516(%rip)
(haven't we fixed this garbled backtrace years before, BTW?)
This doesn't happen when booted from 3.8.1-RELEASE ISO image, or if you seeded the random device before reading from it, so the panic seems to be triggered when the entropy pool is empty. Shouldn't it just block but not panic?
Updated by alexh over 10 years ago
It should definitely not panic; I'll change it to wait until there is entropy in the pool, and then try to reseed again.
Updated by alexh over 10 years ago
- Assignee set to alexh
- Priority changed from Normal to High
Updated by alexh over 10 years ago
- Status changed from New to Feedback
Should be fixed by af641625647f012627fb7e69ee67ebb4bbb6321a.
Updated by dillon over 10 years ago
- Status changed from Feedback to Resolved
Alex fixed the issue, as well as a second issue that was causing excessive blocking on read.
-Matt