linux-kernel - Re: [PATCH v1] PM: sleep: core: Synchronize runtime PM status of parents and children

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: <Z6YcjFBWAVVVANf2@hovoldconsulting.com>
Date: Fri, 7 Feb 2025 15:45:32 +0100
From: Johan Hovold <johan@...nel.org>
To: Jon Hunter <jonathanh@...dia.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Bjorn Helgaas <helgaas@...nel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Kevin Xie <kevin.xie@...rfivetech.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v1] PM: sleep: core: Synchronize runtime PM status of
 parents and children

On Fri, Feb 07, 2025 at 02:50:29PM +0100, Johan Hovold wrote:

> Yeah, I hit something like this yesterday as well and did confirm that
> reverting this commit makes the problem go away. Haven't had time to dig
> much further.
> 
> [  110.522368] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000

> [  110.855238] Call trace:
> [  110.857861]  simple_pm_bus_runtime_suspend+0x14/0x48 (P)
> [  110.863425]  pm_generic_runtime_suspend+0x2c/0x44
> [  110.868362]  pm_runtime_force_suspend+0x54/0x100
> [  110.873217]  dpm_run_callback+0xb4/0x228
> [  110.877347]  device_suspend_noirq+0x70/0x2a8
> [  110.881844]  dpm_noirq_suspend_devices+0xe0/0x230
> [  110.886778]  dpm_suspend_noirq+0x24/0x98
> [  110.890904]  suspend_devices_and_enter+0x368/0x678
> [  110.895941]  pm_suspend+0x1b4/0x348
> [  110.899627]  state_store+0x8c/0xfc
> [  110.903228]  kobj_attr_store+0x18/0x2c
> [  110.907195]  sysfs_kf_write+0x4c/0x78
> [  110.911074]  kernfs_fop_write_iter+0x120/0x1b4
> [  110.915735]  vfs_write+0x2ac/0x358
> [  110.919352]  ksys_write+0x68/0xfc
> [  110.922873]  __arm64_sys_write+0x1c/0x28
> [  110.927002]  invoke_syscall+0x48/0x110
> [  110.930969]  el0_svc_common.constprop.0+0x40/0xe0
> [  110.935907]  do_el0_svc+0x1c/0x28
> [  110.939427]  el0_svc+0x48/0x114
> [  110.942769]  el0t_64_sync_handler+0xc8/0xcc
> [  110.947180]  el0t_64_sync+0x198/0x19c
> [  110.951059] Code: a9be7bfd 910003fd a90153f3 f9403c00 (f9400014)
> [  110.957428] ---[ end trace 0000000000000000 ]---

Ok, so the driver data is never set and runtime PM is never enabled for
this simple bus device, which uses pm_runtime_force_suspend() for system
sleep.

This used to work as the runtime PM state was left at 'suspended', which
makes pm_runtime_force_suspend() return early, but now we can end up
with a call to the driver runtime PM ops that dereference the NULL
driver data.

Johan