From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8734C43381 for ; Mon, 25 Mar 2019 18:36:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92C4220879 for ; Mon, 25 Mar 2019 18:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553538981; bh=NqaxeCG/ea9mYyDAC8FJpmTxF3UoHbqMgex0e27no8I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=I1GL0OaRNoUrjpbUPJAymFGxAwE1oz9welYG59RFs/p3gox/03kP1r8v3kbuAPY5h kvjdenQmk2cooExiLEjGOlDBrnGrUoSEWN+dYZoOUAzU8mJSh0QlGWwQhEgRdEExZw 8MXWRCLxbWsjI9gwzIHRIC3Hb5qkDMXA3wcQbBAY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729840AbfCYSgV (ORCPT ); Mon, 25 Mar 2019 14:36:21 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:40569 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729761AbfCYSgU (ORCPT ); Mon, 25 Mar 2019 14:36:20 -0400 Received: by mail-lf1-f65.google.com with SMTP id u68so6762421lff.7 for ; Mon, 25 Mar 2019 11:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+6DQwypKBF9dmZfO6NUbZVbQzYYRpNxMxq/Erl2LSG0=; b=Luq5lMPb36/UOaaU524GIkqOJtb3MkAtb6ICJJrE/S6b+FWifjwXG7ZmnKqyUF6iqJ XcK4gq6S+9rOTRrMD9nLNgcwXC+YqPzDC3/0H8l827Y4nSmPPcaivxCvOC5GytPC7NSh 4BYkUJrSxOqEgHLEmjkKKiJTVkDjA+HQyuymc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+6DQwypKBF9dmZfO6NUbZVbQzYYRpNxMxq/Erl2LSG0=; b=VghaMTfIqLgWsBK/zKES/xuc2GMcIqUdVLIvY1dh+w4uKx3iP/DjcEnnqpQ4NX7Kav V5LfdWH+wkkTEUbNnqc9dnpFBriXdszzjMunK+Cd+PEFxr4LiBnTOh4K/hs4RxAhsR3g H3KfVrLKOmANtDzQuO2gaGEZH7yQCCxPj6pTFT9ZJPQu3mQeECxHlwxwE5HFD1Y/RlcZ 1ZkrK+whulnQSMnyICbjvMLDmKU4EUIIGaXdREUPox0d0z814n8e63jEKX9Ne17YQM91 5/7G6uBLjenY3hFq7kdHPTDVaSd8fLN15fAgaSk5Di5oczFZ4KCVnWSouvT3MtiwczGq acLA== X-Gm-Message-State: APjAAAWhO4A5oVVqoFl+RZd/SeRnQ7tFZW4HihTqpBAwUiuSXfI+pJCd L2jV/1UajmtBAV2GufFqkyDwXZ5nfjI= X-Google-Smtp-Source: APXvYqxim1qX4kfgpXSvSWAjtbMJMW+9/sATQb+HH62cITgqzrxlPFFUuWP95e5eBs0egE4sM4KYKg== X-Received: by 2002:ac2:4551:: with SMTP id j17mr13903754lfm.141.1553538978470; Mon, 25 Mar 2019 11:36:18 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id y15sm3615451lje.23.2019.03.25.11.36.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 11:36:17 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id q66so8811140ljq.7 for ; Mon, 25 Mar 2019 11:36:17 -0700 (PDT) X-Received: by 2002:a2e:8149:: with SMTP id t9mr14073990ljg.2.1553538977022; Mon, 25 Mar 2019 11:36:17 -0700 (PDT) MIME-Version: 1.0 References: <0000000000006946d2057bbd0eef@google.com> <20190325045744.GK2217@ZenIV.linux.org.uk> In-Reply-To: <20190325045744.GK2217@ZenIV.linux.org.uk> From: Linus Torvalds Date: Mon, 25 Mar 2019 11:36:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KASAN: use-after-free Read in path_lookupat To: Al Viro Cc: syzbot , Alexei Starovoitov , Daniel Borkmann , linux-fsdevel , Linux List Kernel Mailing , syzkaller-bugs Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sun, Mar 24, 2019 at 9:57 PM Al Viro wrote: > > So we have 5 broken cases, all with the same kind of fix: move freeing > into the RCU-delayed part of ->destroy_inode(); for debugfs and bpf > that requires adding ->alloc_inode()/->destroy_inode(), rather than > relying upon the defaults from fs/inode.c The fact that we had five different broken filesystems does imply that we should just make this much easier at the VFS layer instead of forcing filesystems to cope with a bad interface. > > Or maybe we could add a final inode callback function for "rcu_free" > > that is called as the RCU-delayed freeing of the inode itself happens? > > And then people could hook into that for freeing the inode->i_link > > data. > > You mean, split ->destroy_inode() into immediate and RCU-delayed parts? > There are filesystems where both parts are non-empty - we can't just > switch all ->destroy_inode() work to call_rcu(). Right. Not just move the existing destroy_inode() - because as you say, people may not be able to to do that in RCU contect, but split it up, and add a "final_free_inode()" callback or something for the RCU phase. In fact, I suspect that *every* user of destroy_inode() already has to have its own RCU callback to another final freeing function anyway. Because they really shouldn't free the inode itself early. Maybe we can just make that be a generic thing? And no, it's not like the patch to the bpf filesystem looks _horrible_, but I think the fact that the low-level filesystem needed to do its own RCU-deferred thing (even if it wasn't doing any RCU on its own, although bpf obviously has that in other areas) is kind of wrong, and shows that our vfs interfaces are a bit awkward. Plus it's not like it was just bpf that got this wrong. It's also somewhat silly to add _another_ RCU callback when we already have one for the inode. Linus