linux-kernel - Re: [PATCH -v2 1/1] Misc: add sensable phantom driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 3 May 2007 10:36:07 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -v2 1/1] Misc: add sensable phantom driver

On Thu, 03 May 2007 14:40:01 +0200 Jiri Slaby <jirislaby@...il.com> wrote:

> >> +static int phantom_release(struct inode *inode, struct file *file)
> >> +{
> >> +	struct phantom_device *dev = file->private_data;
> >> +
> >> +	if (mutex_lock_interruptible(&dev->open_lock))
> >> +		return -ERESTARTSYS;
> >> +
> >> +	dev->opened = 0;
> >> +	phantom_status(dev, dev->status & ~PHB_RUNNING);
> >> +
> >> +	mutex_unlock(&dev->open_lock);
> >> +
> >> +	return 0;
> >> +}
> > 
> > The mutex_lock_interruptible() is wrong, I think.  This function is called
> > when we do the final close().  If the signal _is_ taken then it's game
> > over: the device can no longer be opened.
> 
> Yes, starving at sys_close, I think so.
> 
> <fast searching in drivers/*>
> 
> Wouldn't this be a problem here too:
> drivers/media/dvb/cinergyT2/cinergyT2.c
> drivers/usb/misc/auerswald.c
> at least that the device won't be stopped or something like that?

Yes, those drivers appear to have the same problem.  I'll fix 'em.

> >> +/*
> >> + * Init and deinit driver
> >> + */
> >> +
> >> +static unsigned int __devinit phantom_get_free(void)
> >> +{
> >> +	unsigned int i;
> >> +
> >> +	for (i = 0; i < PHANTOM_MAX_MINORS; i++)
> >> +		if (phantom_devices[i] == 0)
> >> +			break;
> >> +
> >> +	return i;
> >> +}
> > 
> > This function assumes that the phantom_devices[] array will never have any
> > holes in it.  But if phantom_remove() is called out-of-order, it _will_
> > have holes.  Perhaps - I didn't look too hard.
> 
> I'm afraid I didn't get this. It goes through all phantom_devices and
> returns first free index. If a hole is present it will return "i" which
> corresponds to the hole, because phantom_devices[i] is 0. Note that it is
> unsigned char array.
> 

I guess I must have misread the code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/