linux-kernel - Re: [PATCH v2] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <b410b816-5bf2-02bf-87eb-070bdc485ba5@huaweicloud.com>
Date: Tue, 20 Jan 2026 21:21:11 +0800
From: Li Nan <linan666@...weicloud.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: arnd@...db.de, linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
 wanghai38@...wei.com, "yi.zhang@...wei.com" <yi.zhang@...wei.com>,
 "yangerkun@...wei.com" <yangerkun@...wei.com>
Subject: Re: [PATCH v2] char: lp: Fix NULL pointer dereference of cad



在 2026/1/20 20:43, Greg KH 写道:
> 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

Hi Greg,

Thanks for your patient reply.

Yes, code analysis shows concurrent access to this driver has many issues,
and no problem reports means users don't perform such operations.

Do you think we need cleanups/fixes in this driver, or should we wait
for real-world users to encounter issues and discuss them separately?

-- 
Thanks,
Nan