linux-kernel - Re: BUG: kernel NULL pointer dereference, address: 0000000000000000

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: <aXHeLGr1n-W-Ay44@eldamar.lan>
Date: Thu, 22 Jan 2026 09:22:04 +0100
From: Salvatore Bonaccorso <carnil@...ian.org>
To: Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc: Paul Menzel <pmenzel@...gen.mpg.de>,
	Sudip Mukherjee <sudip.mukherjee@...ethink.co.uk>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	regressions@...ts.linux.dev, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	Hans de Goede <hansg@...nel.org>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Giuseppe Sacco <eppesuig@...ian.org>
Subject: Re: BUG: kernel NULL pointer dereference, address: 0000000000000000

Hi Sudip,

On Sat, Jan 03, 2026 at 11:33:47AM +0000, Sudip Mukherjee wrote:
> On Sat, Jan 03, 2026 at 12:01:19PM +0600, Paul Menzel wrote:
> > Dear Salvatore,
> > 
> > 
> > Thank you for the follow-up.
> > 
> > Am 03.01.26 um 01:59 schrieb Salvatore Bonaccorso:
> > 
> > > On Mon, Dec 01, 2025 at 05:05:59PM +0100, Paul Menzel wrote:
> > 
> > > > Am 01.12.25 um 14:25 schrieb Sudip Mukherjee:
> > > > > On Thu, 27 Nov 2025 at 22:55, Paul Menzel wrote:
> > > > 
> > > > > > Am 27.11.25 um 19:51 schrieb Paul Menzel:
> > > > > > 
> > > > > > > Unfortunately, not reproducible, but starting with Linux 6.18-rc7, I got
> > > > > > > the oops below *once*:
> 
> <snip>
> 
> > > 
> > > https://bugs.debian.org/1124075
> > 
> > This is
> > 
> > AMD AM5 ASUS ROG STRIX B650-A GAMING WIFI, BIOS 3067 12/10/2024
> > 
> > > https://bugs.debian.org/1124463
> > 
> > This is
> > 
> > Dell Latitude E5470/0VHKV0, BIOS 1.34.3 11/20/2022
> > 
> > > Does it make a difference to cold-boot or reboot into the system?
> > 
> > I only did cold boots, and I am not able to reproduce it anymore, and wrote
> > it off to some hardware issue – despite the system working fine otherwise.
> > 
> > I am adding the x86 folks, and regression lists.
> 
> Thanks Salvatore for the Debian bug links.
> 
> I had been trying to reproduce this but have not seen it on my machine so far.
> 
> But looking at the traces from the Debian bugs and the trace from Paul, my best
> guess is that its happening because the low level driver, parport_pc in these
> cases, has not completed setting up the hardware.
> 
> When 'lp' starts registering, parport driver will check if there is any port,
> if no ports are found then it will try to load the low level module.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/parport/share.c?h=v6.19-rc3#n198
> 
> As mentioned in the comment request_module() is not trying to load a real module
> and it depends on the alias. Also, mentioned in the Documentation.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/parport.rst?h=v6.19-rc3#n45
> 
> I am not sure why the problem is seen now, but is it possible to test the
> below diff please and see if that fixes the issue.
> 
> diff --git a/drivers/parport/share.c b/drivers/parport/share.c
> index 427abdf3c4c4a..8f45daf7b3825 100644
> --- a/drivers/parport/share.c
> +++ b/drivers/parport/share.c
> @@ -287,8 +287,16 @@ int __parport_register_driver(struct parport_driver *drv, struct module *owner,
>          */
>         ret = bus_for_each_dev(&parport_bus_type, NULL, NULL,
>                                port_detect);
> -       if (!ret)
> +
> +       /* Return if no port has been found. The driver has been
> +        * registered, so whenever a new port registers
> +        * attach_driver_chain() will be called which will then check
> +        * all registered drivers.
> +        */
> +       if (!ret) {
>                 get_lowlevel_driver();
> +               return 0;
> +       }
>  
>         mutex_lock(&registration_lock);
>         if (drv->match_port)

We had another report (https://bugs.debian.org/1126128_ but the
problem remains here as well the reproducibilty. Uppon several reboots
only the first one so far showed the problem and was not reproducible
afterwards.

Regards,
Salvatore