|Race condition in 0.0.2|
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:
Comments? Flames? Enhancements? Please contact me at email@example.com.