A central processing unit always has to be executing something. If there's nothing to do, it simply loops in an infinite loop, which an interrupt (such as the system heartbeat interrupt) will break it out of.
In older multi-process/multi-threaded operating systems, if the dispatcher (the low-level scheduler that picks and switches to the next thread to run off the runnable threads queue) finds no thread ready to run it would simply enter such an infinite loop.
This is a problem for multi-processor operating systems, though, as the infinite loop is executed in the context of whatever thread the dispatcher was leaving. This could end up with the same thread "running" on two processors at once, which causes a range of problems.
So a more recent (comparatively more recent, that is; as this idea is some several decades old) design was to have, for each processor in the system, an idle thread. This thread does nothing but loop indefinitely, and is always runnable. So there is always a thread that the dispatcher can pick, and there's never a situation where there is no runnable thread for a processor to run.
In old versions of actual Unix, when system initialization has finished, the initialization code has set up data structures describing it as process #0. This has the traditional name of the "swapper process", because of what it did. It had to do something after initialization had finished, so what it did was run the code that swapped process segments between main RAM and the DASD swap area.
The idea of swapping went away in the late 1970s with the advent of demand paging designs; and process #0 became first the idle process and then the system process that contained all of the idle threads.
And that is what is also happening in Linux.
Of course, power management has been a consideration for over a quarter of a century at this point, and the traditional infinite loop of an unconditional branch instruction branching to itself causes a lot of unnecessary busywork and power drain. Modern (again a relative term) idle threads invoke special processor instructions that instruct the executing processor to wait, potentially lowering its clock rate to save power, for it to receive a hardware interrupt. (Over the years on x86 instruction architectures this has changed from
rep nop, trading the complete release of resources by an execution core within a "hyperthreaded" processor for cross-processor shoulder taps that do not involve interrupts, effectively turning idle threads into perpetual waiters for a spin lock.)