In followup to the bug report, and after additional investigation I can report that while a solution has not been finalized yet, this problem has been identified as a fairly rare race condition. It primarily manifests itself in a semi-reproducible fashion because the trigger (copyinstr(0) essentially) is hooked to the write system call, and therefore DTrace's reporting of an invalid address to copyinstr() triggers another instance of the same invalid memory access. Eventually, this chain reaction trips the race condition, and a kernel Oops is reported.
It is important to note that not a single instance of this problem has caused a system crash on our test systems. Certainly, an Oops message is printed by the kernel, and the userspace process issuing the write() that caused the problem will be terminated. But the integrity of the actual kernel is maintained by DTrace, even in this failure mode.