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

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Jan 20, 2026 at 07:41:10PM +0800, Li Nan wrote:
> 
> 
> 在 2026/1/20 17:23, Greg KH 写道:
> > On Tue, Jan 20, 2026 at 03:55:47PM +0800, Li Nan wrote:
> > > > And how was this tested?
> > > 
> > > We found this issue during fuzzing in QEMU.
> > > Based on the root cause, I got the following reproducer:
> > 
> > QEMU is not real hardware :)
> > 
> > Do you really still use parallel port hardware in the real world?  or
> > is this just an accidemic exercise of a fuzzing tool?
> > 
> 
> Yes, the issue was first found in QEMU.
> 
> We do have some parallel port hardware for testing, as this module was
> used by our customers in the past, though we are not sure if it is still
> in active use today. This work is mainly part of routine maintenance.

Look at the big:
	/* !!! LOCKING IS NEEDED HERE */
in parport.c for a hint of maybe what you should be doing here instead.

Your test example says you are allowing multiple users to access the
parport at the same time, which would trigger this problem.  But in the
"real world" that isn't what happens as multiple parport accesses is not
anything that is expected to work well, if at all (the same for serial
ports).

Also remember that this driver was written in the single processor days,
so any locking was added much later, and odds are, is probably
insuffient, to handle multiple accesses.  I'd just prevent this from
happening entirely by not letting your userspace to do this, to make
things much simpler overall.

So while I understand the fuzzing of this is "fun", the real-world
applicability of attempting to add proper multi-user locking to the
parport subsystem might not be a viable thing in the end, as I doubt the
existing users of it need that type of thing.  And the real-world users
of this hardware probably are living just fine without it :)

thanks,

greg k-h