linux-kernel - Re: Uprobe: Bug(?) when probing small binaries

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-prev] [day] [month] [year] [list]

Message-ID: <20180212151935.GA12577@redhat.com>
Date:   Mon, 12 Feb 2018 16:19:35 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>
Cc:     Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
        "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
        ananth@...ux.vnet.ibm.com, lkml <linux-kernel@...r.kernel.org>
Subject: Re: Uprobe: Bug(?) when probing small binaries

Hi Ravi,

On 02/12, Ravi Bangoria wrote:
>
> I'm observing a bug in the uprobe infrastructure.

I am not sure,

> When target binary
> is quite small, uprobe replaces 'trap' instruction at two different
> places. Ex,

but this is actually "the same place" (in the file), just 2 virtual addrs differ,

>   (gdb) x/w 0x1001069c
>     0x1001069c:    2080899750
>
> Now enable the probe:
>
>   # echo 1 > events/probe_a/main/enable
>
> Check probed instruction:
>
>   (gdb) disassemble main
>        0x000000001000069c <+8>:    trap
>
> *Bug*:
>
>   (gdb) x/w 0x1001069c
>     0x1001069c:  2145386504
>
> In short, when it replaces the probe instruction, it does some corruption
> in the readonly vma. This seems to be a bug.
>
> How did I get the other address 0x1001069c?I found build_map_info()
> returns these two vmas for the single probe:
>
>   10000000-10010000 r-xp 00000000 08:05 67325595   /home/ravi/a.out
>   10010000-10020000 r--p 00000000 08:05 67325595   /home/ravi/a.out

please note that these 2 vma's mmap the same region in a.out, so
*0x1001069c and *0x1000069c point to the same insn.

Oleg.