From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752916AbdJaEox (ORCPT <rfc822;w@1wt.eu>);
        Tue, 31 Oct 2017 00:44:53 -0400
Received: from zeniv.linux.org.uk ([195.92.253.2]:37744 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750785AbdJaEow (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 31 Oct 2017 00:44:52 -0400
Date: Tue, 31 Oct 2017 04:44:49 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: Kernel crash in free_pipe_info()
Message-ID: <20171031044449.GJ21978@ZenIV.linux.org.uk>
References: <CAM_iQpXa+orUek72UQ7OM9NiP0uvj_KKBunX7=SSNVrB+i_yEA@mail.gmail.com>
 <CA+55aFwVgYmfe6fFHxEnoAjKrFsDC357PmQ+qE2U2E7wDhgG7Q@mail.gmail.com>
 <CA+55aFzFgomi=xWUxkGxLyU0n1gWQQ+SzvqHUjnAi-8aRPB7Bg@mail.gmail.com>
 <CAM_iQpXEHsc+Yu9UDMmKBgx+fdF9ZNHLrmNrtZ5L0ypFgwr-Zw@mail.gmail.com>
 <CA+55aFypnFvxdZbaqwyZmV_1QzgHE92zu7xsMqAwJ+u-vR=01g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFypnFvxdZbaqwyZmV_1QzgHE92zu7xsMqAwJ+u-vR=01g@mail.gmail.com>
User-Agent: Mutt/1.9.0 (2017-09-02)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Oct 30, 2017 at 07:08:46PM -0700, Linus Torvalds wrote:
> On Mon, Oct 30, 2017 at 6:19 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >
> > 1. The faulty addresses are all near 0000000100000000, with one exception
> > of null (which is the most recent one)
> 
> Well, they're at 8(%rax), except for that last case.

0x10(%rax)?

> And in every case (_including_ that last case), %rax has a very
> interesting pattern.. That's the (bad) buf->ops pointer that  was
> loaded from the somehow corrupted "buf".

> So _if_ this is some kind of use-after-free thing, and the allocation
> got re-used for something else, that might just be related to whatever
> ends up being the offset that is filled in with the (int) error
> number.
> 
> Except the offset is that %r12*0x28+0x10, so we're talking a byte
> offset of 330 bytes into the allocation, and apparently the eight
> previous (0-7) iterations were fine.
> 
> Which is really odd.

I wonder what pipe->buffers is equal to here...

> I'm not seeing anything that makes sense. I'll have to think about this.
> 
> I'm assuming you don't have slub debugging enabled, and no way to
> enable it and try to catch this?

FWIW, I would try to slap
	if (buf->ops && (unsigned long)buf->ops <= 0xffffffff)
		dump the living hell out of that thing
and see what it catches...