Found in kernel/exit.c (at least in linux version 2.4.17, and it's been that way for a while), getting this message is a sign that something is truly going Wrong. The do_exit function of exit.c is used to finally and once-and-for-all exit a task (a process, such as an IRC client or init). Before do_exit actually destroys the process, it checks for three things: is the task processing an interrupt? Does the task have no process ID (PID) (which would mean it's the idle task which does nothing so something is incredibly fucked)? And, Is the process ID 1 (which would mean it's init, as in "initialize"--vital to the health of the system)? If any of these answered Yes, the kernel panics. The one about the interrupt handler gives this message.
Why, I hear you ask, is it necessary to panic in this case? Well, interrupt handlers have to temporarily disable the kernel's function of collecting interrupts (interrupts happen when, for instance, a key is pressed, or a packet is received over the network) so that they can do their job of handling the one they got. The part of an interrupt handler that needs the interrupts to be disabled is called a "lower half," as in low-level code and heavy wizardry. It receives the interrupt just as the kernel gets it (i.e. it is not scheduled like normal tasks; it is executed immediately no matter what), disables interrupts for a moment, sets things up for the upper half (which can be scheduled like normal), re-enables interrupts, and is done.
Lower halves are all parts of the kernel, and (even more so than other parts of the kernel) are written to be utterly bulletproof, so if one of them is exiting that means that the heavy shit is raining down. It also means that interrupts will be disabled; if they were reenabled there would be an interrupt pending that has no handler (as it was just killed). This would mightily confuse the kernel, so it preemptively panics before it has a chance to do any damage.