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: <20210323221940.GA493013@bjorn-Precision-5520>
Date:   Tue, 23 Mar 2021 17:19:40 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Tong Zhang <ztong0001@...il.com>
Cc:     Scott Murray <scott@...teful.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: hotplug: fix null-ptr-dereferencd in cpcihp error
 path

On Sun, Mar 21, 2021 at 01:51:08AM -0400, Tong Zhang wrote:
> There is an issue in the error path, which cpci_thread may remain NULL.
> Calling kthread_stop(cpci_thread) will trigger a BUG().
> It is better to check whether the thread is really created and started
> before stop it.
> 
> [    1.292859] BUG: kernel NULL pointer dereference, address: 0000000000000028
> [    1.293252] #PF: supervisor write access in kernel mode
> [    1.293533] #PF: error_code(0x0002) - not-present page
> [    1.295163] RIP: 0010:kthread_stop+0x22/0x170
> [    1.300491] Call Trace:
> [    1.300628]  cpci_hp_unregister_controller+0xf6/0x130
> [    1.300906]  zt5550_hc_init_one+0x27a/0x27f [cpcihp_zt5550]

Wow, I didn't know anybody actually used this driver :)

> Signed-off-by: Tong Zhang <ztong0001@...il.com>
> ---
>  drivers/pci/hotplug/cpci_hotplug_core.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/hotplug/cpci_hotplug_core.c b/drivers/pci/hotplug/cpci_hotplug_core.c
> index d0559d2faf50..b44da397d631 100644
> --- a/drivers/pci/hotplug/cpci_hotplug_core.c
> +++ b/drivers/pci/hotplug/cpci_hotplug_core.c
> @@ -47,7 +47,7 @@ static atomic_t extracting;
>  int cpci_debug;
>  static struct cpci_hp_controller *controller;
>  static struct task_struct *cpci_thread;
> -static int thread_finished;
> +static int thread_started;

Why are we messing around with "thread_started" or "thread_finished"?
We should know whether cpci_thread has been started by the control
flow.

There are two ways to start cpci_thread:

  1)  cpcihp_generic_init                        # module_init function
        cpci_hp_start
          cpci_start_thread
            cpci_thread = kthread_run(...)

  2)  zt5550_hc_init_one                         # .probe function
        cpci_hp_start
          cpci_start_thread
            cpci_thread = kthread_run(...)

cpci_hp_start() returns a non-zero error if kthread_run() fails, and 
both cpcihp_generic_init() and zt5550_hc_init_one() clean up and exit
in that case.

The error cleanup is a little sloppy: if cpci_hp_register_bus() fails,
cpcihp_generic_init() calls cpci_hp_unregister_controller(), which
stops cpci_thread if it has been started.  But in that case, we *know*
there's no cpci_thread because we haven't even tried to start it.  I
think this error cleanup could be done better by splitting the
cpci_stop_thread() out from cpci_hp_unregister_controller() so it
could be done separately.  zt5550_hc_init_one() has a similar problem.

If cpcihp_generic_init() or zt5550_hc_init_one() succeeds, we *know*
there is a cpci_thread.  We should be able to call kthread_stop() on
it unconditionally in the cpcihp_generic_exit() and
zt5550_hc_remove_one() paths.

What do you think?  It's a little more restructuring work, but I think
"thread_started" and "thread_finished" are basically kind of kludgy
and they add complication without giving me confidence that they're
actually correct.

>  static int enable_slot(struct hotplug_slot *slot);
>  static int disable_slot(struct hotplug_slot *slot);
> @@ -447,7 +447,7 @@ event_thread(void *data)
>  				msleep(500);
>  			} else if (rc < 0) {
>  				dbg("%s - error checking slots", __func__);
> -				thread_finished = 1;
> +				thread_started = 0;
>  				goto out;
>  			}
>  		} while (atomic_read(&extracting) && !kthread_should_stop());
> @@ -479,7 +479,7 @@ poll_thread(void *data)
>  					msleep(500);
>  				} else if (rc < 0) {
>  					dbg("%s - error checking slots", __func__);
> -					thread_finished = 1;
> +					thread_started = 0;
>  					goto out;
>  				}
>  			} while (atomic_read(&extracting) && !kthread_should_stop());
> @@ -501,7 +501,7 @@ cpci_start_thread(void)
>  		err("Can't start up our thread");
>  		return PTR_ERR(cpci_thread);
>  	}
> -	thread_finished = 0;
> +	thread_started = 1;
>  	return 0;
>  }
>  
> @@ -509,7 +509,7 @@ static void
>  cpci_stop_thread(void)
>  {
>  	kthread_stop(cpci_thread);
> -	thread_finished = 1;
> +	thread_started = 0;
>  }
>  
>  int
> @@ -571,7 +571,7 @@ cpci_hp_unregister_controller(struct cpci_hp_controller *old_controller)
>  	int status = 0;
>  
>  	if (controller) {
> -		if (!thread_finished)
> +		if (thread_started)
>  			cpci_stop_thread();
>  		if (controller->irq)
>  			free_irq(controller->irq, controller->dev_id);
> -- 
> 2.25.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ