linux-kernel - Re: WARNING in arch_uprobe_analyze

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

Date:   Tue, 15 May 2018 18:18:18 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     syzbot <syzbot+30d675e3ca03c1c351e7@...kaller.appspotmail.com>,
        bp@...e.de, hpa@...or.com, linux-kernel@...r.kernel.org,
        mingo@...hat.com, ricardo.neri-calderon@...ux.intel.com,
        syzkaller-bugs@...glegroups.com, tglx@...utronix.de,
        x86@...nel.org, yhs@...com
Subject: Re: WARNING in arch_uprobe_analyze_insn

On 05/15, Masami Hiramatsu wrote:
>
> On Tue, 15 May 2018 15:36:30 +0200
> Oleg Nesterov <oleg@...hat.com> wrote:
>
> > Unfortunately, insn_get_length() returns void, and I do not see any
> > insn-was-decoded-correctly helper. Perhaps we should simply remove
> > this WARN_ON() ?
>
> Yes, it should just return an error,

OK, I'll send the fix,

> since user can miss the
> probe address on user binary and we can not make sure
> that is on a instruction boundary.

Or this insn is actually invalid.

> > Alternatively, If am right we can move this check down after the "good_insns"
> > checks, but this doesn't look very clean to me.
>
> I think it is enough if arch_uprobe_analyze_insn() returns an error.
> That makes prepare_uprobe() fail and finally leads uprobe_register()
> fail.

I meant that this way we could probably keep WARN_ON(). Nevermind.

Thanks!

Oleg.