On Thu, 6 Aug 2026 09:23:29 +0200 Luigi Rizzo <[email protected]> wrote:
> On Thu, Aug 6, 2026 at 2:02 AM Masami Hiramatsu <[email protected]> wrote: > > > > On Wed, 5 Aug 2026 16:12:21 +0000 > > Luigi Rizzo <[email protected]> wrote: > > > > > In unregister_kretprobes(), rps[i]->rph can be NULL e.g. when called > > > after kretprobe failed registration. Under !CONFIG_KRETPROBE_ON_RETHOOK, > > > the unconditional access to rps[i]->rph->rp, causes a kernel panic due > > > to NULL pointer dereference. > > > > This is not a bug, since if register_kretprobe(rp) fails, rp must NOT be > > passed to unregister_kretprobe(rp). Or, do you find any cases where > > register_kretprobe() fails, preventing proper cleanup, and requiring > > unregister_kretprobe()? If so, we have to fix that case. > > Masami, you are right, the kernel tree does not call unregister_kretprobes() > on a failed registration. I was confused by the unregister_kretprobes(rps, i); > call in the cleanup in register_kretprobes(), but the failed entry i is > not unregistered). Yes, in that case rps[i] is not unregistered ;) > > So aside from protective coding (but where would one stop ? > null rps, null rps[i], ... ), there is no need for this patch. OK, Thanks for the confirmation! Thanks, > > thanks for the feedback > Luigi -- Masami Hiramatsu (Google) <[email protected]>
