CVE-2026-74363

CVE CVE-2026-74363EUVD EUVD-2026-59510Published 2026-08-15T05:58:46.000ZLast changed 2026-08-17T05:46:21.000ZCVSS 7.8

What the advisory describes

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

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux 6.12.54 <6.12.97; patch: 6.6.145; 6.1.157 <6.1.178; patch: 0; 6.17.4 <6.18; patch: 5.15.212; 743a620c661994c7f0938e6dd32fb0883fb1e0ea <5fecb71c10c28aef276ba49c718dc961745fdcf0; 6.6.113 <6.6.145; patch: 7.2; b6e9645be9eb93f7aff3ca887f8edb6f1d63358f <c70d0f9114c3cc156f6029a400c4eb7e6f7c82b2; 6.18; 4f375ade6aa9f37fd72d7a78682f639772089eed <0497ff765746d9b2d17445c8f7cc737b36c0152a; 5.15.195 <5.15.212; patch: 6.18.40; 4f375ade6aa9f37fd72d7a78682f639772089eed <b93c55b4932dd7e32dca8cf34a3443cc87a02906; e28616ca3d67e745ecb2f10eba4a626e1fc9a203 <ea1c243c39e32b7fc1c2edfe32081ff7e30a877c; patch: 6.12.97; patch: 6.1.178; 4f375ade6aa9f37fd72d7a78682f639772089eed <61f19729728243c82476dee31315143ed3275e7f; de2d2baecc84cc7fca52eec2b9b55d89c93e3565; ee04cff9ed4d6bb25802f5cecfcd0750500410f3 <53649846e0437d1d9b7cb993cfe54c367addf7ae; patch: 7.1.5

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.