This is a note to let you know that I've just added the patch titled s390/kprobes: fix current_kprobe never cleared after kprobes reenter to the 6.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: s390-kprobes-fix-current_kprobe-never-cleared-after-kprobes-reenter.patch and it can be found in the queue-6.1 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable@xxxxxxxxxxxxxxx> know about it. >From cd57953936f2213dfaccce10d20f396956222c7d Mon Sep 17 00:00:00 2001 From: Vasily Gorbik <gor@xxxxxxxxxxxxx> Date: Wed, 1 Mar 2023 17:58:06 +0100 Subject: s390/kprobes: fix current_kprobe never cleared after kprobes reenter From: Vasily Gorbik <gor@xxxxxxxxxxxxx> commit cd57953936f2213dfaccce10d20f396956222c7d upstream. Recent test_kprobe_missed kprobes kunit test uncovers the following problem. Once kprobe is triggered from another kprobe (kprobe reenter), all future kprobes on this cpu are considered as kprobe reenter, thus pre_handler and post_handler are not being called and kprobes are counted as "missed". Commit b9599798f953 ("[S390] kprobes: activation and deactivation") introduced a simpler scheme for kprobes (de)activation and status tracking by using push_kprobe/pop_kprobe, which supposed to work for both initial kprobe entry as well as kprobe reentry and helps to avoid handling those two cases differently. The problem is that a sequence of calls in case of kprobes reenter: push_kprobe() <- NULL (current_kprobe) push_kprobe() <- kprobe1 (current_kprobe) pop_kprobe() -> kprobe1 (current_kprobe) pop_kprobe() -> kprobe1 (current_kprobe) leaves "kprobe1" as "current_kprobe" on this cpu, instead of setting it to NULL. In fact push_kprobe/pop_kprobe can only store a single state (there is just one prev_kprobe in kprobe_ctlblk). Which is a hack but sufficient, there is no need to have another prev_kprobe just to store NULL. To make a simple and backportable fix simply reset "prev_kprobe" when kprobe is poped from this "stack". No need to worry about "kprobe_status" in this case, because its value is only checked when current_kprobe != NULL. Cc: stable@xxxxxxxxxxxxxxx Fixes: b9599798f953 ("[S390] kprobes: activation and deactivation") Reviewed-by: Heiko Carstens <hca@xxxxxxxxxxxxx> Signed-off-by: Vasily Gorbik <gor@xxxxxxxxxxxxx> Signed-off-by: Heiko Carstens <hca@xxxxxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- arch/s390/kernel/kprobes.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/s390/kernel/kprobes.c +++ b/arch/s390/kernel/kprobes.c @@ -279,6 +279,7 @@ static void pop_kprobe(struct kprobe_ctl { __this_cpu_write(current_kprobe, kcb->prev_kprobe.kp); kcb->kprobe_status = kcb->prev_kprobe.status; + kcb->prev_kprobe.kp = NULL; } NOKPROBE_SYMBOL(pop_kprobe); Patches currently in stable-queue which might be from gor@xxxxxxxxxxxxx are queue-6.1/s390-mem_detect-rely-on-diag260-if-sclp_early_get_me.patch queue-6.1/s390-vmem-fix-empty-page-tables-cleanup-under-kasan.patch queue-6.1/s390-boot-fix-mem_detect-extended-area-allocation.patch queue-6.1/s390-kprobes-fix-irq-mask-clobbering-on-kprobe-reenter-from-post_handler.patch queue-6.1/s390-mem_detect-fix-detect_memory-error-handling.patch queue-6.1/s390-mm-ptdump-avoid-kasan-vs-memcpy-real-markers-sw.patch queue-6.1/s390-kprobes-fix-current_kprobe-never-cleared-after-kprobes-reenter.patch