Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 2 Jun 2021 18:00:54 -0500
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     syzbot <syzbot+84fe685c02cd112a2ac3@syzkaller.appspotmail.com>
Cc:     ak@linux.intel.com, bp@alien8.de, hpa@zytor.com,
        inglorion@google.com, linux-kernel@vger.kernel.org,
        mingo@redhat.com, syzkaller-bugs@googlegroups.com,
        tglx@linutronix.de, x86@kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>
Subject: Re: [syzbot] KASAN: stack-out-of-bounds Read in profile_pc
Message-ID: <20210602230054.vyqama2q3koc4bpo@treble>
References: <00000000000030293b05c39afd6f@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <00000000000030293b05c39afd6f@google.com>
Precedence: bulk

On Mon, May 31, 2021 at 12:15:23AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    7ac3a1c1 Merge tag 'mtd/fixes-for-5.13-rc4' of git://git.k..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1246d43dd00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=f9f3fc7daa178986
> dashboard link: https://syzkaller.appspot.com/bug?extid=84fe685c02cd112a2ac3
> compiler:       Debian clang version 11.0.1-2
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+84fe685c02cd112a2ac3@syzkaller.appspotmail.com
> 
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in profile_pc+0xa4/0xe0 arch/x86/kernel/time.c:42
> Read of size 8 at addr ffffc90001c0f7a0 by task systemd-udevd/12323

This looks like a valid bug in profile_pc().  With !FRAME_POINTER, it
has an ancient (2006) hack for unwinding a single frame, for when
regs->ip is in a lock function.

I guess the point is to put lock functions' callees in the profile,
rather than the lock functions themselves.

profile_pc() assumes the return address is either directly at regs->sp,
or one word adjacent to it due to saved flags, both of which are just
completely wrong.  This code has probably never worked with ORC, and
nobody noticed apparently.

We could just use ORC to unwind to the next frame.  Though, isn't
/proc/profile redundant, compared to all the more sophisticated options
nowadays?  Is there still a distinct use case for it or can we just
remove it?

-- 
Josh