From: Al Viro <viro@zeniv.linux.org.uk>
To: Eulgyu Kim <eulgyukim@snu.ac.kr>
Cc: brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, byoungyoung@snu.ac.kr,
jjy600901@snu.ac.kr, Alexei Starovoitov <ast@kernel.org>,
KaFai Wan <kafai.wan@linux.dev>,
Yonghong Song <yonghong.song@linux.dev>,
bpf@vger.kernel.org
Subject: Re: [BUG] KASAN: slab-use-after-free in link_path_walk
Date: Thu, 23 Apr 2026 06:19:25 +0100 [thread overview]
Message-ID: <20260423051925.GO3518998@ZenIV> (raw)
In-Reply-To: <20260423043906.GN3518998@ZenIV>
On Thu, Apr 23, 2026 at 05:39:06AM +0100, Al Viro wrote:
> Folks, the rules are simple:
> * anything that might be accessed in RCU mode (inode very much included
> for objects that are visible in the tree) must be freed after RCU delay; that's
> what ->free_inode() is for.
> * anything that can't be freed in such context should either be
> dealt with in ->destroy_inode() (if it isn't needed for RCU-exposed methods)
> or, if it really is needed for those, done via schedule_work() or equivalent
> done by ->destroy_inode().
If you do ->destroy_inode() alone, you must use an explicit call_rcu() in there
(or in ->evict_inode(), for that matter), with everything that must be RCU-delayed
done via that callback; strongly discouraged, though, since it's easier to leave
that to fs/inode.c by turning that callback into ->free_inode().
> Seeing that bpffs has the grand total of zero RCU-exposed methods (no ->d_compare(),
> no ->d_hash(), no ->permission(), no ->d_revalidate(), no ->get_link()) I would
> guess that it's the case of "have your bpf_any_put() done promptly, leave freeing
> the inode and cached symlink body RCU-delayed".
Other than bpffs there are only two instances of super_operations that have non-NULL
->destroy_inode() and NULL ->free_inode():
static const struct super_operations pipefs_ops = {
.destroy_inode = free_inode_nonrcu,
.statfs = simple_statfs,
};
which is fine, since pipefs inodes are not exposed to RCU pathwalk at all and
static const struct super_operations btrfs_test_super_ops = {
.alloc_inode = btrfs_alloc_inode,
.destroy_inode = btrfs_test_destroy_inode,
};
which is definitely not fine, but since that thing is not exposed to regular
syscalls (only to odd internal selftests, what with not being user-mountable),
presumably it gets away with that. AFAICS, it may end up calling
cond_resched_rwlock_write(&tree->lock);
from drop_all_extent_maps_fast(), from btrfs_drop_extent_map_range(), called
in btrfs_test_destroy_inode(), so it probably needs to leave that call
of btrfs_drop_extent_map_range() in ->destroy_inode() and use their
regular btrfs_free_inode() for ->free_inode().
next prev parent reply other threads:[~2026-04-23 5:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 1:39 [BUG] KASAN: slab-use-after-free in link_path_walk Eulgyu Kim
2026-04-23 4:39 ` Al Viro
2026-04-23 5:19 ` Al Viro [this message]
2026-04-24 1:06 ` Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260423051925.GO3518998@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=byoungyoung@snu.ac.kr \
--cc=eulgyukim@snu.ac.kr \
--cc=jack@suse.cz \
--cc=jjy600901@snu.ac.kr \
--cc=kafai.wan@linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.