From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61402349AE5 for ; Tue, 20 Jan 2026 12:43:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768912997; cv=none; b=ZXa7/p4uS4/1wQjCOKJMKZzxmBA5LbEcFkqNriWDA0lhMFk7ue3DJYCijY5gF2fBlY1AJpJgE2bfDnt4xZwsfYvXQGO0Q0bU+DYYVoF+d/0YJdeVac1YoD4AXILm/CEu+kkn3ZLfGNNsQDxQqbXIzccPqM1KmUkUiYNy794wcw4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768912997; c=relaxed/simple; bh=x1YvnFNgg7bacHbzBBuYRFS4bdmEh6m8rXpRtt4mNo0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cKXu8Aj/KvTbODlCNx0KIcz0wLtB01FfOsr33cSazIath8Gio7ZiDCgk5Fhkl5xNtjyLfns7OEDuYHTgUfHWFGvWciWzbyLj7JT3sr+XQ6j+BT5YItZVsdPiBYAIgexJEJR3z07aeOfGhqS1O64ixAo6ig2WnRk05NUG0g+LbJM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=A6PrKtHW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="A6PrKtHW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B8C3C16AAE; Tue, 20 Jan 2026 12:43:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1768912996; bh=x1YvnFNgg7bacHbzBBuYRFS4bdmEh6m8rXpRtt4mNo0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A6PrKtHW4eC5KF62d+6i09AiT4vap5tXt4QKL9l7c89Gms+ZI+AIhPr+9FH91Aw3O F31aTD85nMSe9AT2gmWK1owXjzDzF5jEQZXITnXV/T7PhhWErAqXD2/Zi6aHs95Qoc NEsX6bsO7R55zu4ddO975McjUG1uo/rbEuLrzm0o= Date: Tue, 20 Jan 2026 13:43:13 +0100 From: Greg KH To: Li Nan Cc: arnd@arndb.de, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, wanghai38@huawei.com, "yi.zhang@huawei.com" , "yangerkun@huawei.com" Subject: Re: [PATCH v2] char: lp: Fix NULL pointer dereference of cad Message-ID: <2026012049-scroll-smog-edf1@gregkh> References: <20260108024155.3800149-1-linan666@huaweicloud.com> <2026011644-glimpse-eatery-c556@gregkh> <2026012041-catfight-fetal-9347@gregkh> <7d2eab46-bad4-3e28-50e7-92a34e22ecd8@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7d2eab46-bad4-3e28-50e7-92a34e22ecd8@huaweicloud.com> 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