Can I block a new process execution using Kprobe?

Kprobe has a pre-handler function vaguely documented as followed:

User's pre-handler (kp->pre_handler)::

    #include <linux/kprobes.h>
    #include <linux/ptrace.h>
    int pre_handler(struct kprobe *p, struct pt_regs *regs);

Called with p pointing to the kprobe associated with the breakpoint,
and regs pointing to the struct containing the registers saved when
the breakpoint was hit.  Return 0 here unless you're a Kprobes geek.

I was wondering if one can use this function (or any other Kprobe feature) to prevent a process from being executed forked.

Answer

As documented in the kernel documentation, you can change the execution path by changing the appropriate register (e.g., IP register in x86):

Changing Execution Path
-----------------------

Since kprobes can probe into a running kernel code, it can change the
register set, including instruction pointer. This operation requires
maximum care, such as keeping the stack frame, recovering the execution
path etc. Since it operates on a running kernel and needs deep knowledge
of computer architecture and concurrent computing, you can easily shoot
your foot.

If you change the instruction pointer (and set up other related
registers) in pre_handler, you must return !0 so that kprobes stops
single stepping and just returns to the given address.
This also means post_handler should not be called anymore.

Note that this operation may be harder on some architectures which use
TOC (Table of Contents) for function call, since you have to setup a new
TOC for your function in your module, and recover the old one after
returning from it.

So you might be able to block a process’ execution by jumping over some code. I wouldn’t recommend it; you’re more likely to cause a kernel crash than to succeed in stopping the execution of a new process.

seccomp-bpf is probably better suited for your use case. This StackOverflow answer gives you all the information you need to leverage seccomp-bpf.