Re: [PATCH v2] char: lp: Fix NULL pointer dereference of cad

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Jan 08, 2026 at 10:41:55AM +0800, linan666@huaweicloud.com wrote:
> From: Li Nan <linan122@huawei.com>
> 
> NULL pointer dereference occurs when accessing 'port->physport->cad'
> as below:
> 
>   KASAN: null-ptr-deref in range [0x00000000000003f0-0x00000000000003f7]
>   RIP: 0010:parport_wait_peripheral+0x130/0x4b0
>   Call Trace:
>    parport_ieee1284_write_compat+0x306/0xb70
>    ? __pfx_parport_ieee1284_write_compat+0x10/0x10
>    parport_write+0x1d6/0x660
>    lp_write+0x43e/0xbc0
>    ? __pfx_lp_write+0x10/0x10
>    vfs_write+0x21c/0x960
>    ksys_write+0x12e/0x260
>    ? __pfx_ksys_write+0x10/0x10
>    ? __audit_syscall_entry+0x39e/0x510
>    do_syscall_64+0x59/0x110
>    entry_SYSCALL_64_after_hwframe+0x78/0xe2
> 
> The root cause is other processes may set 'port->cad' to NULL during
> lp_write() operations. Process flow:
> 
>   T1					T2
>   lp_write
>    lock port_mutex *
>    lp_claim_parport_or_block
>     parport_claim
>      port->cad = dev;
>    parport_write
>     parport_ieee1284_write_compat
> 					lp_do_ioctl
> 					 lp_reset
> 					  lp_release_parport
> 					   parport_release
> 					    port->cad = NULL;
>      parport_wait_peripheral
>       port->physport->cad->timeout
> 		       |
> 		      NULL
> 
> Fix this issue by adding 'port_mutex' protection. Like read/write and
> ioctl LPGETSTATUS, use this lock to protect port access and modification
> to prevent concurrency problems.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Li Nan <linan122@huawei.com>
> ---
> v2: Use mutex_lock instead of mutex_lock_interruptible in lp_release().
> 
>  drivers/char/lp.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/char/lp.c b/drivers/char/lp.c
> index 24417a00dfe9..82f2405b4502 100644
> --- a/drivers/char/lp.c
> +++ b/drivers/char/lp.c
> @@ -520,9 +520,14 @@ static int lp_open(struct inode *inode, struct file *file)
>  	   should most likely only ever be used by the tunelp application. */
>  	if ((LP_F(minor) & LP_ABORTOPEN) && !(file->f_flags & O_NONBLOCK)) {
>  		int status;
> +		if (mutex_lock_interruptible(&lp_table[minor].port_mutex)) {
> +			ret = -EINTR;
> +			goto out;
> +		}
>  		lp_claim_parport_or_block(&lp_table[minor]);
>  		status = r_str(minor);
>  		lp_release_parport(&lp_table[minor]);
> +		mutex_unlock(&lp_table[minor].port_mutex);
>  		if (status & LP_POUTPA) {
>  			printk(KERN_INFO "lp%d out of paper\n", minor);
>  			LP_F(minor) &= ~LP_BUSY;
> @@ -547,6 +552,10 @@ static int lp_open(struct inode *inode, struct file *file)
>  		goto out;
>  	}
>  	/* Determine if the peripheral supports ECP mode */
> +	if (mutex_lock_interruptible(&lp_table[minor].port_mutex)) {
> +		ret = -EINTR;
> +		goto out;
> +	}
>  	lp_claim_parport_or_block(&lp_table[minor]);
>  	if ((lp_table[minor].dev->port->modes & PARPORT_MODE_ECP) &&
>  	     !parport_negotiate(lp_table[minor].dev->port,
> @@ -559,6 +568,7 @@ static int lp_open(struct inode *inode, struct file *file)
>  	/* Leave peripheral in compatibility mode */
>  	parport_negotiate(lp_table[minor].dev->port, IEEE1284_MODE_COMPAT);
>  	lp_release_parport(&lp_table[minor]);
> +	mutex_unlock(&lp_table[minor].port_mutex);
>  	lp_table[minor].current_mode = IEEE1284_MODE_COMPAT;
>  out:
>  	mutex_unlock(&lp_mutex);
> @@ -569,10 +579,13 @@ static int lp_release(struct inode *inode, struct file *file)
>  {
>  	unsigned int minor = iminor(inode);
>  
> +	/* ->release should never fail. Use uninterruptible mutex variant */
> +	mutex_lock(&lp_table[minor].port_mutex);

But could stall for a very long time, right?  That's not a good idea if
possible.

And how was this tested?

thanks,

greg k-h