linux-kernel - uprobes: bug in comm/string output?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <bf358673-ceb2-65bf-80c9-4b1c09a8a264@fau.de>
Date:   Mon, 14 Jan 2019 13:38:19 +0100
From:   Andreas Ziegler <andreas.ziegler@....de>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: uprobes: bug in comm/string output?

Hi,

I've been playing around with uprobes today and found the following weird 
behaviour/output when using more than one string argument (or using the $comm 
argument). This was run on a v4.20 mainline build on Ubuntu 18.04.

root@...ntu1810:~# uname -a
Linux ubuntu1810 4.20.0-042000-generic #201812232030 SMP Mon Dec 24 01:32:58 UTC 
2018 x86_64 x86_64 x86_64 GNU/Linux

I'm trying to track calls to dlopen so I'm looking up the correct offset in 
libdl.so:

root@...ntu1810:/sys/kernel/debug/tracing# readelf -s 
/lib/x86_64-linux-gnu/libdl-2.28.so | grep dlopen
     34: 00000000000012a0   133 FUNC    GLOBAL DEFAULT   14 dlopen@@GLIBC_2.2.5

Then I'm creating a uprobe with two prints of $comm and two prints of the first 
argument to dlopen, and enable that probe. The '/root/test' program only does a 
dlopen("libc.so.6", RTLD_LAZY) in main().

root@...ntu1810:/sys/kernel/debug/tracing# echo 'p:dlopen 
/lib/x86_64-linux-gnu/libdl-2.28.so:0x12a0 $comm $comm +0(%di):string 
+0(%di):string' > uprobe_events
root@...ntu1810:/sys/kernel/debug/tracing# echo 1 > events/uprobes/dlopen/enable
root@...ntu1810:/sys/kernel/debug/tracing# /root/test

The trace output looks like this:

root@...ntu1810:/sys/kernel/debug/tracing# cat trace
# tracer: nop
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
             test-1617  [000] d...  1237.959168: dlopen: (0x7fbd5272e2a0) 
arg1=(fault) arg2=(fault) arg3="libc.so.6libc.so.6" arg4="libc.so.6"

That's very weird for two reasons:
- fetching $comm seems to fail with an invalid pointer
- arg3 contains the text twice (if I add another print of the argument, arg3 
will contain the wanted string three times, arg4 two times and the last argument 
will contain it once).

On the "standard" kernel shipped with Ubuntu 18.04 (4.18) printing $comm works 
but also "accumulates" (in lack of a better word) the later string arguments in 
the earlier output arguments, so for the probe above arg1 would be 
"testtestlibc.so.6libc.so.6", arg2 would be "testlibc.so.6libc.so.6" and 
arg3/arg4 will be the same as in the output above.

Is there anything in the documentation why multiple string outputs might not 
work with uprobes? Am I installing the uprobe wrong? Or is this a bug?

I found that the kprobe selftest at 
tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_string.tc contains a 
similar situation for kprobes (it prints the parameter two times) which works 
fine on the same system.

Regards,

Andreas

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5450 bytes)