linux-kernel - Re: [PATCH] char: lp: Fix NULL pointer dereference of cad

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]

Message-ID: <2026011601-geometric-grading-ceb7@gregkh>
Date: Fri, 16 Jan 2026 15:38:09 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Li Nan <linan666@...weicloud.com>
Cc: Al Viro <viro@...iv.linux.org.uk>, arnd@...db.de,
	linux-kernel@...r.kernel.org, "wanghai (M)" <wanghai38@...wei.com>
Subject: Re: [PATCH] char: lp: Fix NULL pointer dereference of cad

On Tue, Dec 30, 2025 at 10:52:02AM +0800, Li Nan wrote:
> 
> 
> 在 2025/12/30 10:10, Al Viro 写道:
> > On Tue, Dec 30, 2025 at 09:51:43AM +0800, Li Nan wrote:
> > > Friendly ping...
> > 
> > > > @@ -569,10 +579,13 @@ static int lp_release(struct inode *inode, struct file *file)
> > > >    {
> > > >    	unsigned int minor = iminor(inode);
> > > > +	if (mutex_lock_interruptible(&lp_table[minor].port_mutex))
> > > > +		return -EINTR;
> > 
> > ->release() return value is never checked, simply because there is nothing
> > to do with it.  It will *not* leave file opened - it will simply leak,
> > with no way to recover from that.
> > 
> > If you need to report some errors on close, do that in ->flush().
> > If you ever see ->release() returning a non-zero value, you are very
> > likely looking at deeply confused code.
> > 
> > Don't do that.  ->release() can't fail, period.  It should've been
> > void (*release)(struct file *), but for historical reasons it returns
> > int and there are too many instances to change that.
> 
> Thank you for your patient explanation.
> 
> Would it be acceptable to switch to mutex_lock() here? Looking at the code
> and historical changes, I don't see a compelling reason for the interruptible
> function here.

release should not stall forever like that, so be careful.

Also, do you really have this hardware to test this with?  I'm sure
there are loads of other cleanups / fixes needed in this driver that no
one has done just because they don't have this hardware anymore.
Getting a new maintainer for it would be great.

thanks,

greg k-h