ACK: [SRU][N/O][PATCH v2 0/1] uprobe-related panics during profiling

[Kuba Pawlak]

On 26.03.2025 18:44, Krister Johansen wrote:
> BugLink: https://bugs.launchpad.net/bugs/2104210
>
> [Impact]
>
> On systems that utilize both uprobes and perf_events style profiling, it
> is possible to hit a panic in the uprobe_free_utask code.  This occurs
> during process exit.  If the profiler fires while uprobe_free_utask is
> in the process of cleaning up the utask, the NMI may read freed memory
> because the cleanup code frees the utask before setting its pointer to
> NULL.  This submitter has encountered the problem on systems running
> workloads without intentionally trying to trigger the problem.
>
> The stacks look something like this:
>
>   RIP: 0010:is_uprobe_at_func_entry+0x28/0x80
>   ...
>    ? die_addr+0x36/0x90
>    ? exc_general_protection+0x217/0x420
>    ? asm_exc_general_protection+0x26/0x30
>    ? is_uprobe_at_func_entry+0x28/0x80
>    perf_callchain_user+0x20a/0x360
>    get_perf_callchain+0x147/0x1d0
>    bpf_get_stackid+0x60/0x90
>    bpf_prog_9aac297fb833e2f5_do_perf_event+0x434/0x53b
>    ? __smp_call_single_queue+0xad/0x120
>    bpf_overflow_handler+0x75/0x110
>    ...
>    asm_sysvec_apic_timer_interrupt+0x1a/0x20
>   RIP: 0010:__kmem_cache_free+0x1cb/0x350
>   ...
>    ? uprobe_free_utask+0x62/0x80
>    ? acct_collect+0x4c/0x220
>    uprobe_free_utask+0x62/0x80
>    mm_release+0x12/0xb0
>    do_exit+0x26b/0xaa0
>    __x64_sys_exit+0x1b/0x20
>    do_syscall_64+0x5a/0x80
>
> The person who reported the issue upstream provided this reproducer.
> (Run each command in a separate terminal):
>
>    # while :; do bpftrace -e 'uprobe:/bin/ls:_start  { printf("hit\n"); }' -c ls; done
>    # bpftrace -e 'profile:hz:100000 { @[ustack()] = count(); }'
>
> However, since the binutils are stripped on some of the releases where I
> tested this, I ran the following instead:
>
>    # while :; do bpftrace -e 'uprobe:libc:malloc  { printf("hit\n"); }' -c ls; done
>    # bpftrace -e 'profile:hz:100000 { @[ustack()] = count(); }'
>
> [Backport]
> The fix is upstream as commit b583ef82b671 ("uprobes: Fix race in
> uprobe_free_utask")
>
> However this patch was massaged by stable for its inclusion in 6.12,
> 6.6, and 6.1.  Instead of re-doing stable's conflict resolution, take
> the patch directly from 6.6.x instead, at commit eff00c5e29ab.
>
> This patch is in stable as of 6.12.19, 6.6.83, and 6.1.131.
>
> [Test]
>
> I've run the provided reproducer and validated that I can reproduce the
> problem without the patch applied and that I cannot reproduce it again
> once I have applied the patch.
>
> [Potential Regression]
>
> The regression potential here seems quite low.  The fix has been
> upstream for a couple releases and no subsequent issues have been
> reported.  It makes no functional change beyond ensuring that the utask
> pointer is set to NULL before the utask structure itself is freed.  The
> dereference and free occur on the same cpu.
>
> [Additonal Info]
> v2: ensure attached patch's comment body conforms to formatting guidelines
>
> Jiri Olsa (1):
>    uprobes: Fix race in uprobe_free_utask
>
>   kernel/events/uprobes.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Kuba Pawlak <kuba.pawlak at canonical.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x216A9D7E3B63DCB4.asc
Type: application/pgp-keys
Size: 3139 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250327/b4494370/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250327/b4494370/attachment.sig>