On Mon, Oct 19, 2026 at 02:37:39PM +0530, Naman Jain wrote: > > > On 10/19/2026 2:13 PM, Daehyeon Ko wrote: > > MSHV_SET_POLL_FILE retains one embedded wait entry per CPU after vfs_poll() > > returns. Two independent bugs affect that state. > > > > First, a provider such as signalfd may retire a non-file-owned waitqueue > > with POLLFREE. The MSHV callback leaves its entry linked and retains the > > queue pointer, allowing a later replacement to access freed provider > > memory. Patch 1 detaches on POLLFREE and introduces an RCU-safe removal > > helper. > > > > Second, a poll callback may register more than one waitqueue. MSHV inserts > > the same embedded list node into each queue, corrupting the first list. > > Patch 2 rejects a second distinct queue and uses the common helper to > > unwind the first registration. > > > > The roots, triggers, effects, and runtime oracles remain independent. > > Source-equivalent KASAN/LOCKDEP tests reproduced both bugs and validated > > the fixes. The local system is not a Hyper-V VTL2 environment, so the > > series has not been exercised through the real MSHV ioctl. OpenVMM does > > not exercise these paths in its current use of the interface. > > > > An LLM assisted the source audits, fix development, and validation. Each > > patch notes that assistance in its changelog. > > > > Changes in v2: > > - combine the two previously standalone fixes into one series; > > - rebase onto current Torvalds master; > > - introduce the removal helper in patch 1 and reuse it in patch 2; > > - replace the obsolete Assisted-by trailer with changelog prose. > > > > Previous standalone submissions: > > - POLLFREE v1: <[email protected]> > > - multi-waitqueue v2, now withdrawn: > > <[email protected]> > > > > Daehyeon Ko (2): > > mshv_vtl: detach poll waiter on POLLFREE > > mshv_vtl: reject poll files with multiple waitqueues > > > > drivers/hv/mshv_vtl_main.c | 51 ++++++++++++++++++++++++++++++++++---- > > 1 file changed, 46 insertions(+), 5 deletions(-) > > > > > > base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222 > > I would suggest you to generally wait for a couple more days to collect > other reviewers feedback as well, in case someone is reviewing your changes. > You can then address them together in the next version. > > For the series, > Reviewed-by: Naman Jain <[email protected]>
Applied. Wei
