[PATCH] ntsync: Check for owner in setup_wait()

[PATCH] ntsync: Check for owner in setup_wait()

[Griffin Kroah-Hartman]

Add a check to see if any mutex owner is 0.

As stated in the uapi documentation , this is a failure case that was
not being checked under the NTSYNC_IOC_WAIT_ANY and NTSYNC_IOC_WAIT_ALL
cases, which state that mutexes with no owner should fail the ioctl with
-EINVAL.

Assisted-by: gkh_clanker_t1000
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
---
 drivers/misc/ntsync.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c
index 02c9d1192812..4a805919bb0c 100644
--- a/drivers/misc/ntsync.c
+++ b/drivers/misc/ntsync.c
@@ -875,6 +875,9 @@ static int setup_wait(struct ntsync_device *dev,
 	if (args->pad || (args->flags & ~NTSYNC_WAIT_REALTIME))
 		return -EINVAL;
 
+	if (!args->owner)
+		return -EINVAL;
+
 	if (size >= sizeof(fds))
 		return -EINVAL;
 

---
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
change-id: 20260714-ntsync_patches_1-34ea98de8606

Best regards,
--  
Griffin Kroah-Hartman <griffin@kroah.com>

Re: [PATCH] ntsync: Check for owner in setup_wait()

[Elizabeth Figura]

On Tuesday, 14 July 2026 10:36:46 CDT Griffin Kroah-Hartman wrote:
> Add a check to see if any mutex owner is 0.
> 
> As stated in the uapi documentation , this is a failure case that was
> not being checked under the NTSYNC_IOC_WAIT_ANY and NTSYNC_IOC_WAIT_ALL
> cases, which state that mutexes with no owner should fail the ioctl with
> -EINVAL.

This has already been sent I'm afraid:

https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/

Re: [PATCH] ntsync: Check for owner in setup_wait()

[Greg Kroah-Hartman]

On Tue, Jul 14, 2026 at 12:16:47PM -0500, Elizabeth Figura wrote:
> On Tuesday, 14 July 2026 10:36:46 CDT Griffin Kroah-Hartman wrote:
> > Add a check to see if any mutex owner is 0.
> > 
> > As stated in the uapi documentation , this is a failure case that was
> > not being checked under the NTSYNC_IOC_WAIT_ANY and NTSYNC_IOC_WAIT_ALL
> > cases, which state that mutexes with no owner should fail the ioctl with
> > -EINVAL.
> 
> This has already been sent I'm afraid:
> 
> https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/

Cool, but that series wasn't sent to the maintainers to get them merged,
and there's going to be a second version as it conflicts with your
previous patches, right?

Or are you going to batch these up and send them to Arnd and me for
inclusion later on?

And is the wine-devel list still alive?  If not, we should probably drop
that from the MAINTAINERS file.

thanks,

greg k-h

Re: [PATCH] ntsync: Check for owner in setup_wait()

[Elizabeth Figura]

On Tuesday, 14 July 2026 23:56:35 CDT Greg Kroah-Hartman wrote:
> On Tue, Jul 14, 2026 at 12:16:47PM -0500, Elizabeth Figura wrote:
> > On Tuesday, 14 July 2026 10:36:46 CDT Griffin Kroah-Hartman wrote:
> > > Add a check to see if any mutex owner is 0.
> > > 
> > > As stated in the uapi documentation , this is a failure case that was
> > > not being checked under the NTSYNC_IOC_WAIT_ANY and NTSYNC_IOC_WAIT_ALL
> > > cases, which state that mutexes with no owner should fail the ioctl with
> > > -EINVAL.
> > 
> > This has already been sent I'm afraid:
> > 
> > https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/
> 
> Cool, but that series wasn't sent to the maintainers to get them merged,
> and there's going to be a second version as it conflicts with your
> previous patches, right?
> 
> Or are you going to batch these up and send them to Arnd and me for
> inclusion later on?

Ah I'm sorry, I missed that those patches weren't sent to Arnd and you. I'll resend them. The previous patches are in the same situation, but I think these cover a superset of the same ground so I'll just send them alone.

> And is the wine-devel list still alive?  If not, we should probably drop
> that from the MAINTAINERS file.

It's alive, but the address moved. I forgot that this reference needed to be updated; I apologize for that. I sent a fix there as <https://lore.kernel.org/all/20260701183214.13973-1-zfigura@codeweavers.com/>. I guess that should also have been sent to you as the relevant subsystem maintainers; I failed to properly think that one through.