Hi,

Some users of the "/dev/random" DLKM (version 0.0.2) reported a system panic with a stack trace that included the random DLKM. The stack trace looks like this:

0x400003ffffff2000 0x00037228 lbcopy+0x28
0x400003ffffff2000 0x00037704 privlbcopy+0x1c
0x400003ffffff1fa0 0x01584784 random_strategy+0xe4
0x400003ffffff1cb0 0x001afbbc lv_startpv+0x1a4
0x400003ffffff1be0 0x001afe78 lv_begin+0x128
0x400003ffffff1b60 0x001b0674 lv_parallel+0x38c
0x400003ffffff1950 0x001119c0 lv_schedule+0x580
0x400003ffffff17a0 0x00111428 lv_initiate+0x690

I analyzed the problem to be a race condition where a kernel buffer is freed by the interrupt service before the random DKLM accesses it. By the time the random DLKM gets back control, the buffer is freed and random's attempt to retrieve data from the buffer results in a reference to an invalid memory address.

The problem has been fixed in 0.0.3 by:

1. Only processing SCSI write instructions.
2. Taking the entropy from the buffer *before* continuing the SCSI I/O

Comments? Flames? Enhancements? Please contact me at josv@osp.nl.