Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Nice work.

I am the submitter of CVE-2026-43074. I also think this is a separate bug. The fix for CVE-2026-43074 RCU-defers freeing of struct eventpoll for the RCU graph walks in ep_get_upwards_depth_proc() / reverse_path_check_proc(). That does break the pre-07712db8 eventpoll-UAF-based exploit path here: while __ep_remove() holds file->f_lock, the spinlocked region is covered by RCU read-side protection, so the RCU-deferred struct eventpoll free cannot complete inside that window and the struct eventpoll UAF primitive is removed.

However, that does not fix the underlying file-release race. The struct file UAF remains. Fixing CVE-2026-46242 should not require RCU-deferring struct eventpoll lifetime; the effect of 07712db8 here is only to remove one exploit primitive as a side effect, not to fix this bug.

We found that this submission does not pass vuln-verify under the current setup, for two reasons described in docs/vulnerability.md:

1. The eventpoll UAF, which is the primitive used by our exploit, is no longer observable on kernel_wo_patch. A separate follow-up fix, merged after our submission, made the struct eventpoll free RCU-deferred. Because this bug's race window runs with a spinlock held, the struct eventpoll is no longer freed/reclaimed inside that window, so the eventpoll UAF disappears.

2. The remaining struct file UAF / invalid-free signal is not observable under the default KASAN-based configuration, where CONFIG_SLUB_RCU_DEBUG is enabled along with KASAN.

   i) struct file UAF: Because struct file is SLAB_TYPESAFE_BY_RCU, KASAN skips poisoning the object when it is freed, so the UAF access does not produce a KASAN report.

   ii) Invalid-free: With CONFIG_SLUB_RCU_DEBUG=y, reuse of freed SLAB_TYPESAFE_BY_RCU objects is deferred until after an RCU grace period, so the freed struct file object is not reclaimed immediately. Without that immediate reclaim, the invalid free is not exposed.

Would it be acceptable for this submission not to pass vuln-verify?

@J-jaeyoung Thank you for the detailed explanation. We reviewed the timeline and the impact of the patch collision with CVE-2026-43074 (commit 07712db8). Your explanation regarding the RCU-deferred free inside the spinlock window and the KASAN blindspot for SLAB_TYPESAFE_BY_RCU objects makes sense.

Since the exploit was fully valid against the target before the collision occurred, we are granting an exception for the vuln-verify failure. I have marked the vulnerability as verified and we will proceed with the payout process :)