Typically upon control+c being mashed in a shell (unless the terminal is in raw mode or such) a SIGINT signal is sent to all members of the foreground process group, and most of the processes in that group (ideally, probably) go away. This usually includes a portion of the shell (which forked itself to spawn the pipeline or whatever, to call setpgid(2), etc) that usually ignores the signal. In this case it may seem like the OS is doing something, but really it's shell job control (assuming your shell has job control, which most now do, and that you haven't turned "monitor" off, which most folks do not). The kernel is mostly there for shuttling signals around and process bookkeeping.

However a different process management model is that each parent must in turn signal its child processes to exit, in which case if the parent dies before that can happen you easily get orphan processes. There are use cases for both the process group model and individual signal models, and pros and cons to each.

When a child process finishes (that is not actively being waited on) it is left in a "defunct" or "zombie" state and will stick around in the process table until the parent process waits on them to fetch exit code. When you kill a parent process with active children, these subprocesses will become orphaned and re-parented to the OS pid 1 (or another "sub-reaper" process depending on your setup).

The OS will typically not kill orphaned/re-parented processes for you. It will simply wait/reap them so they are not left as zombies once they complete. If your parent process spawns something like a daemon server that needs an explicit signal to be stopped (e.g. SIGINT/SIGTERM), these processes will continue to run in the background until they are manually killed or they crash.