The code executed on a unix system is classified as either kernel code or user land code. User land code is always attached to a process, so if the CPU is busy executing user land code, it shows on some line in
top. Kernel code is normally attached to a process: if the kernel is executing a system call, then the in-kernel processing is accounted as belonging to that process. Kernel time is the “system time” reported by the
Some of the things that the kernel does can't be directly accounted against one process. In particular, hardware interrupts don't intrinsically belong to a particular process. For example, suppose that an interrupt is triggered by the network card. The kernel executes code to read and parse the network packet; so far no process is involved. The packet may be rejected via a firewall rule, in which case no process can claim that processing time. If a process ends up receiving that packet, some of the reception time will be put on that process's tab, but not the early stages.
So it's possible to have CPU time that doesn't belong to any process. Yet sometimes that CPU time is indirectly caused by some process. For example, if there's a process that sends packets to another machine and causes this other machine to reply, but the firewall blocks the reply packets, then the time spent parsing and discarding the reply packets won't be traced back to that sending process; but if the sending process stops, which causes the remote machine to stop replying, then the kernel won't spend time rejecting the packets any more. Of course the network is just one example, there are many other ways for the kernel to do things that can't be traced directly to one process.
You haven't given enough information to be sure that this is what is going on (and it can be difficult to figure out without a kernel debugger), but this is a plausible explanation.