From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-74363: bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs
Date: Sat, 15 Aug 2026 15:11:30 +0900 [thread overview]
Message-ID: <2026081501-CVE-2026-74363-e3cf@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs
commit 4f375ade6aa9 ("bpf: Avoid RCU context warning when unpinning
htab with internal structs") moved inode cleanup from ->free_inode()
into ->destroy_inode() to avoid sleeping in RCU context when calling
bpf_any_put(). However this removed the RCU delay on freeing the
inode itself and the cached symlink body (i_link), both of which
can be accessed by RCU pathwalk (pick_link, may_lookup etc.).
This causes a use-after-free when a concurrent unlinkat() drops the
last inode reference and destroy_inode() frees the inode immediately,
while another task is still walking the path in RCU mode and reads
inode->i_opflags (offset +2) inside current_time() -> is_mgtime().
KASAN reports:
BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313
Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags)
The rules (per Al Viro):
->destroy_inode() called immediately, can sleep, use for blocking
cleanup e.g. bpf_any_put()
->free_inode() called after RCU grace period, use for freeing
inode and anything RCU-accessible e.g. i_link
Fix: split the two concerns properly:
- keep bpf_any_put() in bpf_destroy_inode() since it is blocking
and needs to run promptly
- introduce bpf_free_inode() to handle kfree(i_link) and
free_inode_nonrcu() with proper RCU delay, preventing the UAF
The Linux kernel CVE team has assigned CVE-2026-74363 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.15.195 with commit e28616ca3d67e745ecb2f10eba4a626e1fc9a203 and fixed in 5.15.212 with commit ea1c243c39e32b7fc1c2edfe32081ff7e30a877c
Issue introduced in 6.1.157 with commit 743a620c661994c7f0938e6dd32fb0883fb1e0ea and fixed in 6.1.178 with commit 5fecb71c10c28aef276ba49c718dc961745fdcf0
Issue introduced in 6.6.113 with commit b6e9645be9eb93f7aff3ca887f8edb6f1d63358f and fixed in 6.6.145 with commit c70d0f9114c3cc156f6029a400c4eb7e6f7c82b2
Issue introduced in 6.12.54 with commit ee04cff9ed4d6bb25802f5cecfcd0750500410f3 and fixed in 6.12.97 with commit 53649846e0437d1d9b7cb993cfe54c367addf7ae
Issue introduced in 6.18 with commit 4f375ade6aa9f37fd72d7a78682f639772089eed and fixed in 6.18.40 with commit 61f19729728243c82476dee31315143ed3275e7f
Issue introduced in 6.18 with commit 4f375ade6aa9f37fd72d7a78682f639772089eed and fixed in 7.1.5 with commit 0497ff765746d9b2d17445c8f7cc737b36c0152a
Issue introduced in 6.18 with commit 4f375ade6aa9f37fd72d7a78682f639772089eed and fixed in 7.2-rc1 with commit b93c55b4932dd7e32dca8cf34a3443cc87a02906
Issue introduced in 6.17.4 with commit de2d2baecc84cc7fca52eec2b9b55d89c93e3565
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-74363
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
kernel/bpf/inode.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/ea1c243c39e32b7fc1c2edfe32081ff7e30a877c
https://git.kernel.org/stable/c/5fecb71c10c28aef276ba49c718dc961745fdcf0
https://git.kernel.org/stable/c/c70d0f9114c3cc156f6029a400c4eb7e6f7c82b2
https://git.kernel.org/stable/c/53649846e0437d1d9b7cb993cfe54c367addf7ae
https://git.kernel.org/stable/c/61f19729728243c82476dee31315143ed3275e7f
https://git.kernel.org/stable/c/0497ff765746d9b2d17445c8f7cc737b36c0152a
https://git.kernel.org/stable/c/b93c55b4932dd7e32dca8cf34a3443cc87a02906
reply other threads:[~2026-08-15 6:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=2026081501-CVE-2026-74363-e3cf@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox