[PATCH] spi: fsl-dspi: fix NULL pointer dereference

[PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Qiang Zhao]

From: Zhao Qiang <qiang.zhao@nxp.com>

Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in
remove path"), this driver causes a kernel oops:

[   64.587431] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000020
[..]
[   64.756080] Call trace:
[   64.758526]  dspi_suspend+0x30/0x78
[   64.762012]  platform_pm_suspend+0x28/0x70
[   64.766107]  dpm_run_callback.isra.19+0x24/0x70
[   64.770635]  __device_suspend+0xf4/0x2f0
[   64.774553]  dpm_suspend+0xec/0x1e0
[   64.778036]  dpm_suspend_start+0x80/0xa0
[   64.781957]  suspend_devices_and_enter+0x118/0x4f0
[   64.786743]  pm_suspend+0x1e0/0x260
[   64.790227]  state_store+0x8c/0x118
[   64.793712]  kobj_attr_store+0x18/0x30
[   64.797459]  sysfs_kf_write+0x40/0x58
[   64.801118]  kernfs_fop_write+0x148/0x240
[   64.805126]  vfs_write+0xc0/0x230
[   64.808436]  ksys_write+0x6c/0x100
[   64.811833]  __arm64_sys_write+0x1c/0x28
[   64.815753]  el0_svc_common.constprop.3+0x68/0x170
[   64.820541]  do_el0_svc+0x24/0x90
[   64.823853]  el0_sync_handler+0x118/0x168
[   64.827858]  el0_sync+0x158/0x180

This is because since this commit, the drivers private data point to
"dspi" instead of "ctlr", the codes in suspend and resume func were
not modified correspondly.

Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
 drivers/spi/spi-fsl-dspi.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 3967afa..1a08c1d 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1080,12 +1080,11 @@ MODULE_DEVICE_TABLE(of, fsl_dspi_dt_ids);
 #ifdef CONFIG_PM_SLEEP
 static int dspi_suspend(struct device *dev)
 {
-	struct spi_controller *ctlr = dev_get_drvdata(dev);
-	struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
+	struct fsl_dspi *dspi = dev_get_drvdata(dev);
 
 	if (dspi->irq)
 		disable_irq(dspi->irq);
-	spi_controller_suspend(ctlr);
+	spi_controller_suspend(dspi->ctlr);
 	clk_disable_unprepare(dspi->clk);
 
 	pinctrl_pm_select_sleep_state(dev);
@@ -1095,8 +1094,7 @@ static int dspi_suspend(struct device *dev)
 
 static int dspi_resume(struct device *dev)
 {
-	struct spi_controller *ctlr = dev_get_drvdata(dev);
-	struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
+	struct fsl_dspi *dspi = dev_get_drvdata(dev);
 	int ret;
 
 	pinctrl_pm_select_default_state(dev);
@@ -1104,7 +1102,7 @@ static int dspi_resume(struct device *dev)
 	ret = clk_prepare_enable(dspi->clk);
 	if (ret)
 		return ret;
-	spi_controller_resume(ctlr);
+	spi_controller_resume(dspi->ctlr);
 	if (dspi->irq)
 		enable_irq(dspi->irq);
 
-- 
2.7.4

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Vladimir Oltean]

On Thu, Oct 29, 2020 at 04:40:35PM +0800, Qiang Zhao wrote:
> From: Zhao Qiang <qiang.zhao@nxp.com>
> 
> Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in
> remove path"), this driver causes a kernel oops:
> 
> [   64.587431] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000020
> [..]
> [   64.756080] Call trace:
> [   64.758526]  dspi_suspend+0x30/0x78
> [   64.762012]  platform_pm_suspend+0x28/0x70
> [   64.766107]  dpm_run_callback.isra.19+0x24/0x70
> [   64.770635]  __device_suspend+0xf4/0x2f0
> [   64.774553]  dpm_suspend+0xec/0x1e0
> [   64.778036]  dpm_suspend_start+0x80/0xa0
> [   64.781957]  suspend_devices_and_enter+0x118/0x4f0
> [   64.786743]  pm_suspend+0x1e0/0x260
> [   64.790227]  state_store+0x8c/0x118
> [   64.793712]  kobj_attr_store+0x18/0x30
> [   64.797459]  sysfs_kf_write+0x40/0x58
> [   64.801118]  kernfs_fop_write+0x148/0x240
> [   64.805126]  vfs_write+0xc0/0x230
> [   64.808436]  ksys_write+0x6c/0x100
> [   64.811833]  __arm64_sys_write+0x1c/0x28
> [   64.815753]  el0_svc_common.constprop.3+0x68/0x170
> [   64.820541]  do_el0_svc+0x24/0x90
> [   64.823853]  el0_sync_handler+0x118/0x168
> [   64.827858]  el0_sync+0x158/0x180
> 
> This is because since this commit, the drivers private data point to
> "dspi" instead of "ctlr", the codes in suspend and resume func were
> not modified correspondly.
> 
> Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
> Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
> ---

Please update your tree.
https://github.com/torvalds/linux/commit/6e3837668e00fb914ac2b43158ef51b027ec385c

RE: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Qiang Zhao]

On Thu, Oct 29, 2020 at 19:03PM, Vladimir Oltean <olteanv@gmail.com> wrote:


> -----Original Message-----
> From: Vladimir Oltean <olteanv@gmail.com>
> Sent: 2020年10月29日 19:03
> To: Qiang Zhao <qiang.zhao@nxp.com>
> Cc: broonie@kernel.org; linux-spi@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
> 
> On Thu, Oct 29, 2020 at 04:40:35PM +0800, Qiang Zhao wrote:
> > From: Zhao Qiang <qiang.zhao@nxp.com>
> >
> > Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in
> > remove path"), this driver causes a kernel oops:
> >
> > [   64.587431] Unable to handle kernel NULL pointer dereference at
> > virtual address 0000000000000020
> > [..]
> > [   64.756080] Call trace:
> > [   64.758526]  dspi_suspend+0x30/0x78
> > [   64.762012]  platform_pm_suspend+0x28/0x70
> > [   64.766107]  dpm_run_callback.isra.19+0x24/0x70
> > [   64.770635]  __device_suspend+0xf4/0x2f0
> > [   64.774553]  dpm_suspend+0xec/0x1e0
> > [   64.778036]  dpm_suspend_start+0x80/0xa0
> > [   64.781957]  suspend_devices_and_enter+0x118/0x4f0
> > [   64.786743]  pm_suspend+0x1e0/0x260
> > [   64.790227]  state_store+0x8c/0x118
> > [   64.793712]  kobj_attr_store+0x18/0x30
> > [   64.797459]  sysfs_kf_write+0x40/0x58
> > [   64.801118]  kernfs_fop_write+0x148/0x240
> > [   64.805126]  vfs_write+0xc0/0x230
> > [   64.808436]  ksys_write+0x6c/0x100
> > [   64.811833]  __arm64_sys_write+0x1c/0x28
> > [   64.815753]  el0_svc_common.constprop.3+0x68/0x170
> > [   64.820541]  do_el0_svc+0x24/0x90
> > [   64.823853]  el0_sync_handler+0x118/0x168
> > [   64.827858]  el0_sync+0x158/0x180
> >
> > This is because since this commit, the drivers private data point to
> > "dspi" instead of "ctlr", the codes in suspend and resume func were
> > not modified correspondly.
> >
> > Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
> > path")
> > Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
> > ---
> 
> Please update your tree.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
> om%2Ftorvalds%2Flinux%2Fcommit%2F6e3837668e00fb914ac2b43158ef51b0
> 27ec385c&amp;data=04%7C01%7Cqiang.zhao%40nxp.com%7C50171bf65a5e
> 4f24e0c208d87bfa3fe9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C637395662023835048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sda
> ta=NlmOj1SfvKu2V7nrSYF3lDji25xbP5PeDl1PcwlKyr4%3D&amp;reserved=0

I saw the patch, it just fix the issue when the kernel are booted up.
But there still have the issue when the driver suspend and resume. 

Best Regards
Qiang Zhao

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On Thu, Oct 29, 2020 at 04:40:35PM +0800, Qiang Zhao wrote:

> [   64.587431] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000020
> [..]
> [   64.756080] Call trace:
> [   64.758526]  dspi_suspend+0x30/0x78
> [   64.762012]  platform_pm_suspend+0x28/0x70
> [   64.766107]  dpm_run_callback.isra.19+0x24/0x70
> [   64.770635]  __device_suspend+0xf4/0x2f0
> [   64.774553]  dpm_suspend+0xec/0x1e0
> [   64.778036]  dpm_suspend_start+0x80/0xa0
> [   64.781957]  suspend_devices_and_enter+0x118/0x4f0
> [   64.786743]  pm_suspend+0x1e0/0x260
> [   64.790227]  state_store+0x8c/0x118
> [   64.793712]  kobj_attr_store+0x18/0x30
> [   64.797459]  sysfs_kf_write+0x40/0x58
> [   64.801118]  kernfs_fop_write+0x148/0x240
> [   64.805126]  vfs_write+0xc0/0x230
> [   64.808436]  ksys_write+0x6c/0x100
> [   64.811833]  __arm64_sys_write+0x1c/0x28
> [   64.815753]  el0_svc_common.constprop.3+0x68/0x170
> [   64.820541]  do_el0_svc+0x24/0x90
> [   64.823853]  el0_sync_handler+0x118/0x168
> [   64.827858]  el0_sync+0x158/0x180

Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative (it often is
for search engines if nothing else) then it's usually better to pull out
the relevant sections.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Vladimir Oltean]

On Fri, Oct 30, 2020 at 02:04:06AM +0000, Qiang Zhao wrote:
> I saw the patch, it just fix the issue when the kernel are booted up.
> But there still have the issue when the driver suspend and resume. 

I see, sorry, I only paid attention to the commit message since it
wasn't explicit that it is about the suspend/resume case. Let me look
closer at the patch.

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Vladimir Oltean]

On Thu, Oct 29, 2020 at 04:40:35PM +0800, Qiang Zhao wrote:
> From: Zhao Qiang <qiang.zhao@nxp.com>
> 
> Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in
> remove path"), this driver causes a kernel oops:
> 
> [   64.587431] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000020
> [..]
> [   64.756080] Call trace:
> [   64.758526]  dspi_suspend+0x30/0x78
> [   64.762012]  platform_pm_suspend+0x28/0x70
> [   64.766107]  dpm_run_callback.isra.19+0x24/0x70
> [   64.770635]  __device_suspend+0xf4/0x2f0
> [   64.774553]  dpm_suspend+0xec/0x1e0
> [   64.778036]  dpm_suspend_start+0x80/0xa0
> [   64.781957]  suspend_devices_and_enter+0x118/0x4f0
> [   64.786743]  pm_suspend+0x1e0/0x260
> [   64.790227]  state_store+0x8c/0x118
> [   64.793712]  kobj_attr_store+0x18/0x30
> [   64.797459]  sysfs_kf_write+0x40/0x58
> [   64.801118]  kernfs_fop_write+0x148/0x240
> [   64.805126]  vfs_write+0xc0/0x230
> [   64.808436]  ksys_write+0x6c/0x100
> [   64.811833]  __arm64_sys_write+0x1c/0x28
> [   64.815753]  el0_svc_common.constprop.3+0x68/0x170
> [   64.820541]  do_el0_svc+0x24/0x90
> [   64.823853]  el0_sync_handler+0x118/0x168
> [   64.827858]  el0_sync+0x158/0x180
> 
> This is because since this commit, the drivers private data point to
> "dspi" instead of "ctlr", the codes in suspend and resume func were
> not modified correspondly.
> 
> Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
> Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
> ---

Reviewed-by: Vladimir Oltean <olteanv@gmail.com>

Please resend with Mark's comment. I would prefer that you even remove
the stack trace completely and make it more obvious in the commit
message itself that the NULL pointer occurs during suspend/resume.
Somehow that managed to get obscured in your current version. It is also
not helpful at all that there already exists a commit titled 'spi:
fsl-dspi: fix NULL pointer dereference' on this driver. This causes
confusion for backporters. Please provide a unique commit message.
Thanks.

RE: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Qiang Zhao]

On Thu, Oct 30, 2020 at 21:02PM, Mark Brown <broonie@kernel.org> wrote:

> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: 2020年10月30日 21:02
> To: Qiang Zhao <qiang.zhao@nxp.com>
> Cc: olteanv@gmail.com; linux-spi@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
> 
> On Thu, Oct 29, 2020 at 04:40:35PM +0800, Qiang Zhao wrote:
> 
> > [   64.587431] Unable to handle kernel NULL pointer dereference at
> > virtual address 0000000000000020
> > [..]
> > [   64.756080] Call trace:
> > [   64.758526]  dspi_suspend+0x30/0x78
> > [   64.762012]  platform_pm_suspend+0x28/0x70
> > [   64.766107]  dpm_run_callback.isra.19+0x24/0x70
> > [   64.770635]  __device_suspend+0xf4/0x2f0
> > [   64.774553]  dpm_suspend+0xec/0x1e0
> > [   64.778036]  dpm_suspend_start+0x80/0xa0
> > [   64.781957]  suspend_devices_and_enter+0x118/0x4f0
> > [   64.786743]  pm_suspend+0x1e0/0x260
> > [   64.790227]  state_store+0x8c/0x118
> > [   64.793712]  kobj_attr_store+0x18/0x30
> > [   64.797459]  sysfs_kf_write+0x40/0x58
> > [   64.801118]  kernfs_fop_write+0x148/0x240
> > [   64.805126]  vfs_write+0xc0/0x230
> > [   64.808436]  ksys_write+0x6c/0x100
> > [   64.811833]  __arm64_sys_write+0x1c/0x28
> > [   64.815753]  el0_svc_common.constprop.3+0x68/0x170
> > [   64.820541]  do_el0_svc+0x24/0x90
> > [   64.823853]  el0_sync_handler+0x118/0x168
> > [   64.827858]  el0_sync+0x158/0x180
> 
> Please think hard before including complete backtraces in upstream reports,
> they are very large and contain almost no useful information relative to their
> size so often obscure the relevant content in your message. If part of the
> backtrace is usefully illustrative (it often is for search engines if nothing else)
> then it's usually better to pull out the relevant sections.

Ok, will modified in next version.

Best Regards,
Qiang Zhao

RE: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Qiang Zhao]

On Thu, Oct 30, 2020 at 21:18PM +0800, Vladimir Oltean <olteanv@gmail.com> wrote:

> -----Original Message-----
> From: Vladimir Oltean <olteanv@gmail.com>
> Sent: 2020年10月30日 21:18
> To: Qiang Zhao <qiang.zhao@nxp.com>
> Cc: broonie@kernel.org; linux-spi@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
> 
> On Thu, Oct 29, 2020 at 04:40:35PM +0800, Qiang Zhao wrote:
> > From: Zhao Qiang <qiang.zhao@nxp.com>
> >
> > Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in
> > remove path"), this driver causes a kernel oops:
> >
> > [   64.587431] Unable to handle kernel NULL pointer dereference at
> > virtual address 0000000000000020
> > [..]
> > [   64.756080] Call trace:
> > [   64.758526]  dspi_suspend+0x30/0x78
> > [   64.762012]  platform_pm_suspend+0x28/0x70
> >
> > This is because since this commit, the drivers private data point to
> > "dspi" instead of "ctlr", the codes in suspend and resume func were
> > not modified correspondly.
> >
> > Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
> > path")
> > Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
> > ---
> 
> Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
> 
> Please resend with Mark's comment. I would prefer that you even remove the
> stack trace completely and make it more obvious in the commit message itself
> that the NULL pointer occurs during suspend/resume.
> Somehow that managed to get obscured in your current version. It is also not
> helpful at all that there already exists a commit titled 'spi:
> fsl-dspi: fix NULL pointer dereference' on this driver. This causes confusion for
> backporters. Please provide a unique commit message.
> Thanks.

How about it looks like below:

    spi: fsl-dspi: fix wrong pointer in suspend/resume

    Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in
    remove path"), this driver causes a "NULL pointer dereference"
    in dspi_suspend/resume.
    This is because since this commit, the drivers private data point to
    "dspi" instead of "ctlr", the codes in suspend and resume func were
    not modified correspondly.


Best Regards,
Qiang Zhao

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Vladimir Oltean]

On Mon, Nov 02, 2020 at 02:19:28AM +0000, Qiang Zhao wrote:
> How about it looks like below:
> 
>     spi: fsl-dspi: fix wrong pointer in suspend/resume
> 
>     Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in
>     remove path"), this driver causes a "NULL pointer dereference"
>     in dspi_suspend/resume.
>     This is because since this commit, the drivers private data point to
>     "dspi" instead of "ctlr", the codes in suspend and resume func were
>     not modified correspondly.

Looks ok.

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Mark Brown]

On Thu, 29 Oct 2020 16:40:35 +0800, Qiang Zhao wrote:
> Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in
> remove path"), this driver causes a kernel oops:
> 
> [   64.587431] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000020
> [..]
> [   64.756080] Call trace:
> [   64.758526]  dspi_suspend+0x30/0x78
> [   64.762012]  platform_pm_suspend+0x28/0x70
> [   64.766107]  dpm_run_callback.isra.19+0x24/0x70
> [   64.770635]  __device_suspend+0xf4/0x2f0
> [   64.774553]  dpm_suspend+0xec/0x1e0
> [   64.778036]  dpm_suspend_start+0x80/0xa0
> [   64.781957]  suspend_devices_and_enter+0x118/0x4f0
> [   64.786743]  pm_suspend+0x1e0/0x260
> [   64.790227]  state_store+0x8c/0x118
> [   64.793712]  kobj_attr_store+0x18/0x30
> [   64.797459]  sysfs_kf_write+0x40/0x58
> [   64.801118]  kernfs_fop_write+0x148/0x240
> [   64.805126]  vfs_write+0xc0/0x230
> [   64.808436]  ksys_write+0x6c/0x100
> [   64.811833]  __arm64_sys_write+0x1c/0x28
> [   64.815753]  el0_svc_common.constprop.3+0x68/0x170
> [   64.820541]  do_el0_svc+0x24/0x90
> [   64.823853]  el0_sync_handler+0x118/0x168
> [   64.827858]  el0_sync+0x158/0x180
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: fsl-dspi: fix wrong pointer in suspend/resume
      commit: 9bd77a9ce31dd242fece27219d14fbee5068dd85

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Krzysztof Kozlowski]

On Mon, Sep 28, 2020 at 09:46:22AM +0200, Michael Walle wrote:
> Am 2020-09-28 09:29, schrieb Krzysztof Kozlowski:
> > On Mon, 28 Sep 2020 at 01:28, Vladimir Oltean <olteanv@gmail.com> wrote:
> > > 
> > > On Mon, Sep 28, 2020 at 12:43:36AM +0200, Michael Walle wrote:
> > > > Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
> > > > path") this driver causes a kernel oops:
> > > >
> > > > [    1.891065] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
> > > > [    1.899889] Mem abort info:
> > > > [    1.902692]   ESR = 0x96000004
> > > > [    1.905754]   EC = 0x25: DABT (current EL), IL = 32 bits
> > > > [    1.911089]   SET = 0, FnV = 0
> > > > [    1.914156]   EA = 0, S1PTW = 0
> > > > [    1.917303] Data abort info:
> > > > [    1.920193]   ISV = 0, ISS = 0x00000004
> > > > [    1.924044]   CM = 0, WnR = 0
> > > > [    1.927022] [0000000000000080] user address but active_mm is swapper
> > > > [    1.933403] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > > > [    1.938995] Modules linked in:
> > > > [    1.942060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc6-next-20200925-00026-gae556cc74e28-dirty #94
> > > > [    1.951838] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
> > > > [    1.960135] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> > > > [    1.966168] pc : dspi_setup+0xc8/0x2e0
> > > > [    1.969926] lr : dspi_setup+0xbc/0x2e0
> > > > [    1.973684] sp : ffff80001139b930
> > > > [    1.977005] x29: ffff80001139b930 x28: ffff00207a5d2000
> > > > [    1.982338] x27: 0000000000000006 x26: ffff00207a44d410
> > > > [    1.987669] x25: ffff002079c08100 x24: ffff00207a5d2400
> > > > [    1.993000] x23: ffff00207a5d2600 x22: ffff800011169948
> > > > [    1.998332] x21: ffff800010cbcd20 x20: ffff00207a58a800
> > > > [    2.003663] x19: ffff00207a76b700 x18: 0000000000000010
> > > > [    2.008994] x17: 0000000000000001 x16: 0000000000000019
> > > > [    2.014326] x15: ffffffffffffffff x14: 0720072007200720
> > > > [    2.019657] x13: 0720072007200720 x12: ffff8000111fc5e0
> > > > [    2.024989] x11: 0000000000000003 x10: ffff8000111e45a0
> > > > [    2.030320] x9 : 0000000000000000 x8 : ffff00207a76b780
> > > > [    2.035651] x7 : 0000000000000000 x6 : 000000000000003f
> > > > [    2.040982] x5 : 0000000000000040 x4 : ffff80001139b918
> > > > [    2.046313] x3 : 0000000000000001 x2 : 64b62cc917af5100
> > > > [    2.051643] x1 : 0000000000000000 x0 : 0000000000000000
> > > > [    2.056973] Call trace:
> > > > [    2.059425]  dspi_setup+0xc8/0x2e0
> > > > [    2.062837]  spi_setup+0xcc/0x248
> > > > [    2.066160]  spi_add_device+0xb4/0x198
> > > > [    2.069918]  of_register_spi_device+0x250/0x370
> > > > [    2.074462]  spi_register_controller+0x4f4/0x770
> > > > [    2.079094]  dspi_probe+0x5bc/0x7b0
> > > > [    2.082594]  platform_drv_probe+0x5c/0xb0
> > > > [    2.086615]  really_probe+0xec/0x3c0
> > > > [    2.090200]  driver_probe_device+0x60/0xc0
> > > > [    2.094308]  device_driver_attach+0x7c/0x88
> > > > [    2.098503]  __driver_attach+0x60/0xe8
> > > > [    2.102263]  bus_for_each_dev+0x7c/0xd0
> > > > [    2.106109]  driver_attach+0x2c/0x38
> > > > [    2.109692]  bus_add_driver+0x194/0x1f8
> > > > [    2.113538]  driver_register+0x6c/0x128
> > > > [    2.117385]  __platform_driver_register+0x50/0x60
> > > > [    2.122105]  fsl_dspi_driver_init+0x24/0x30
> > > > [    2.126302]  do_one_initcall+0x54/0x2d0
> > > > [    2.130149]  kernel_init_freeable+0x1ec/0x258
> > > > [    2.134520]  kernel_init+0x1c/0x120
> > > > [    2.138018]  ret_from_fork+0x10/0x34
> > > > [    2.141606] Code: 97e0b11d aa0003f3 b4000680 f94006e0 (f9404000)
> > > > [    2.147723] ---[ end trace 26cf63e6cbba33a8 ]---
> > > > [    2.152374] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > > > [    2.160061] SMP: stopping secondary CPUs
> > > > [    2.163999] Kernel Offset: disabled
> > > > [    2.167496] CPU features: 0x0040022,20006008
> > > > [    2.171777] Memory Limit: none
> > > > [    2.174840] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> > > >
> > > > This is because since this commit, the allocation of the drivers private
> > > > data is done explicitly and in this case spi_alloc_master() won't set the
> > > > correct pointer.
> > > >
> > > > Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
> > > > Signed-off-by: Michael Walle <michael@walle.cc>
> > > > ---
> > > 
> > > Sascha, how did you test commit 530b5affc675?
> > 
> > Hi,
> > 
> > I just hit it on my Vybrid systems as well. It fails on every boot, so
> > I have doubts that it was actually tested. The fix was posted on 23rd
> > and applied within a few hours... also no time for anyone else to test
> > it.
> 
> Mhh, given the benefit of the doubt, I could imagine that the allocs align
> up in a way, that the pointer is valid afterwards, no?

Or Sasha used generic evalkit board, where SPI by default might not have
any devices attached.

> > > 
> > > >  drivers/spi/spi-fsl-dspi.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > > > index a939618f5e47..dd80be987bf9 100644
> > > > --- a/drivers/spi/spi-fsl-dspi.c
> > > > +++ b/drivers/spi/spi-fsl-dspi.c
> > > > @@ -1236,6 +1236,8 @@ static int dspi_probe(struct platform_device *pdev)
> > > >       if (!ctlr)
> > > >               return -ENOMEM;
> > > >
> > > > +     spi_controller_set_devdata(ctlr, dspi);
> > 
> > Michael,
> > 
> > How about moving here platform_set_drvdata(pdev, dspi) from the end of
> > the probe to keep them close to each other?
> 
> Given that this patch has a fixes tag, I'd rather keep the changes to a
> minimum to avoid future conflicts.
> 
> OTOH I don't know if its better if the "move platform_set_drvdata()" is in a
> seperate patch, conflict-wise.

Just looking at these two patches there are no worries:
1. The original patch does not target stable,
2. The fix is only for this cycle.

However it is likely that autosel will pick up these patches so your
questions are good. If I understand code correctly, these two calls
(spi_controller_set_devdata and platform_set_drvdata) can be reordered
freely between allocation and spi_register_controller(). Therefore
moving these calls around should not affect backporting to stable.

I would propose to keep these calls together, either at beginning or
just before spi_register_controller().

Best regards,
Krzysztof


> 
> Any suggestions?
> 
> -michael

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Sascha Hauer]

On Mon, Sep 28, 2020 at 02:27:47AM +0300, Vladimir Oltean wrote:
> On Mon, Sep 28, 2020 at 12:43:36AM +0200, Michael Walle wrote:
> > Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
> > path") this driver causes a kernel oops:
> > 
> > [    1.891065] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
> > [    1.899889] Mem abort info:
> > [    1.902692]   ESR = 0x96000004
> > [    1.905754]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [    1.911089]   SET = 0, FnV = 0
> > [    1.914156]   EA = 0, S1PTW = 0
> > [    1.917303] Data abort info:
> > [    1.920193]   ISV = 0, ISS = 0x00000004
> > [    1.924044]   CM = 0, WnR = 0
> > [    1.927022] [0000000000000080] user address but active_mm is swapper
> > [    1.933403] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > [    1.938995] Modules linked in:
> > [    1.942060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc6-next-20200925-00026-gae556cc74e28-dirty #94
> > [    1.951838] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
> > [    1.960135] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> > [    1.966168] pc : dspi_setup+0xc8/0x2e0
> > [    1.969926] lr : dspi_setup+0xbc/0x2e0
> > [    1.973684] sp : ffff80001139b930
> > [    1.977005] x29: ffff80001139b930 x28: ffff00207a5d2000
> > [    1.982338] x27: 0000000000000006 x26: ffff00207a44d410
> > [    1.987669] x25: ffff002079c08100 x24: ffff00207a5d2400
> > [    1.993000] x23: ffff00207a5d2600 x22: ffff800011169948
> > [    1.998332] x21: ffff800010cbcd20 x20: ffff00207a58a800
> > [    2.003663] x19: ffff00207a76b700 x18: 0000000000000010
> > [    2.008994] x17: 0000000000000001 x16: 0000000000000019
> > [    2.014326] x15: ffffffffffffffff x14: 0720072007200720
> > [    2.019657] x13: 0720072007200720 x12: ffff8000111fc5e0
> > [    2.024989] x11: 0000000000000003 x10: ffff8000111e45a0
> > [    2.030320] x9 : 0000000000000000 x8 : ffff00207a76b780
> > [    2.035651] x7 : 0000000000000000 x6 : 000000000000003f
> > [    2.040982] x5 : 0000000000000040 x4 : ffff80001139b918
> > [    2.046313] x3 : 0000000000000001 x2 : 64b62cc917af5100
> > [    2.051643] x1 : 0000000000000000 x0 : 0000000000000000
> > [    2.056973] Call trace:
> > [    2.059425]  dspi_setup+0xc8/0x2e0
> > [    2.062837]  spi_setup+0xcc/0x248
> > [    2.066160]  spi_add_device+0xb4/0x198
> > [    2.069918]  of_register_spi_device+0x250/0x370
> > [    2.074462]  spi_register_controller+0x4f4/0x770
> > [    2.079094]  dspi_probe+0x5bc/0x7b0
> > [    2.082594]  platform_drv_probe+0x5c/0xb0
> > [    2.086615]  really_probe+0xec/0x3c0
> > [    2.090200]  driver_probe_device+0x60/0xc0
> > [    2.094308]  device_driver_attach+0x7c/0x88
> > [    2.098503]  __driver_attach+0x60/0xe8
> > [    2.102263]  bus_for_each_dev+0x7c/0xd0
> > [    2.106109]  driver_attach+0x2c/0x38
> > [    2.109692]  bus_add_driver+0x194/0x1f8
> > [    2.113538]  driver_register+0x6c/0x128
> > [    2.117385]  __platform_driver_register+0x50/0x60
> > [    2.122105]  fsl_dspi_driver_init+0x24/0x30
> > [    2.126302]  do_one_initcall+0x54/0x2d0
> > [    2.130149]  kernel_init_freeable+0x1ec/0x258
> > [    2.134520]  kernel_init+0x1c/0x120
> > [    2.138018]  ret_from_fork+0x10/0x34
> > [    2.141606] Code: 97e0b11d aa0003f3 b4000680 f94006e0 (f9404000)
> > [    2.147723] ---[ end trace 26cf63e6cbba33a8 ]---
> > [    2.152374] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > [    2.160061] SMP: stopping secondary CPUs
> > [    2.163999] Kernel Offset: disabled
> > [    2.167496] CPU features: 0x0040022,20006008
> > [    2.171777] Memory Limit: none
> > [    2.174840] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> > 
> > This is because since this commit, the allocation of the drivers private
> > data is done explicitly and in this case spi_alloc_master() won't set the
> > correct pointer.
> > 
> > Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
> > Signed-off-by: Michael Walle <michael@walle.cc>
> > ---
> 
> Sascha, how did you test commit 530b5affc675?

My intention was to test it, but it seems I somehow failed to copy the
new kernel onto my target without noticing it, shame on me. Anyway, I
get the same kernel panic with my patch appied now and this patch fixes
it.

Tested-by: Sascha Hauer <s.hauer@pengutronix.de>

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Michael Walle]

Am 2020-09-28 09:29, schrieb Krzysztof Kozlowski:
> On Mon, 28 Sep 2020 at 01:28, Vladimir Oltean <olteanv@gmail.com> 
> wrote:
>> 
>> On Mon, Sep 28, 2020 at 12:43:36AM +0200, Michael Walle wrote:
>> > Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
>> > path") this driver causes a kernel oops:
>> >
>> > [    1.891065] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
>> > [    1.899889] Mem abort info:
>> > [    1.902692]   ESR = 0x96000004
>> > [    1.905754]   EC = 0x25: DABT (current EL), IL = 32 bits
>> > [    1.911089]   SET = 0, FnV = 0
>> > [    1.914156]   EA = 0, S1PTW = 0
>> > [    1.917303] Data abort info:
>> > [    1.920193]   ISV = 0, ISS = 0x00000004
>> > [    1.924044]   CM = 0, WnR = 0
>> > [    1.927022] [0000000000000080] user address but active_mm is swapper
>> > [    1.933403] Internal error: Oops: 96000004 [#1] PREEMPT SMP
>> > [    1.938995] Modules linked in:
>> > [    1.942060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc6-next-20200925-00026-gae556cc74e28-dirty #94
>> > [    1.951838] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
>> > [    1.960135] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
>> > [    1.966168] pc : dspi_setup+0xc8/0x2e0
>> > [    1.969926] lr : dspi_setup+0xbc/0x2e0
>> > [    1.973684] sp : ffff80001139b930
>> > [    1.977005] x29: ffff80001139b930 x28: ffff00207a5d2000
>> > [    1.982338] x27: 0000000000000006 x26: ffff00207a44d410
>> > [    1.987669] x25: ffff002079c08100 x24: ffff00207a5d2400
>> > [    1.993000] x23: ffff00207a5d2600 x22: ffff800011169948
>> > [    1.998332] x21: ffff800010cbcd20 x20: ffff00207a58a800
>> > [    2.003663] x19: ffff00207a76b700 x18: 0000000000000010
>> > [    2.008994] x17: 0000000000000001 x16: 0000000000000019
>> > [    2.014326] x15: ffffffffffffffff x14: 0720072007200720
>> > [    2.019657] x13: 0720072007200720 x12: ffff8000111fc5e0
>> > [    2.024989] x11: 0000000000000003 x10: ffff8000111e45a0
>> > [    2.030320] x9 : 0000000000000000 x8 : ffff00207a76b780
>> > [    2.035651] x7 : 0000000000000000 x6 : 000000000000003f
>> > [    2.040982] x5 : 0000000000000040 x4 : ffff80001139b918
>> > [    2.046313] x3 : 0000000000000001 x2 : 64b62cc917af5100
>> > [    2.051643] x1 : 0000000000000000 x0 : 0000000000000000
>> > [    2.056973] Call trace:
>> > [    2.059425]  dspi_setup+0xc8/0x2e0
>> > [    2.062837]  spi_setup+0xcc/0x248
>> > [    2.066160]  spi_add_device+0xb4/0x198
>> > [    2.069918]  of_register_spi_device+0x250/0x370
>> > [    2.074462]  spi_register_controller+0x4f4/0x770
>> > [    2.079094]  dspi_probe+0x5bc/0x7b0
>> > [    2.082594]  platform_drv_probe+0x5c/0xb0
>> > [    2.086615]  really_probe+0xec/0x3c0
>> > [    2.090200]  driver_probe_device+0x60/0xc0
>> > [    2.094308]  device_driver_attach+0x7c/0x88
>> > [    2.098503]  __driver_attach+0x60/0xe8
>> > [    2.102263]  bus_for_each_dev+0x7c/0xd0
>> > [    2.106109]  driver_attach+0x2c/0x38
>> > [    2.109692]  bus_add_driver+0x194/0x1f8
>> > [    2.113538]  driver_register+0x6c/0x128
>> > [    2.117385]  __platform_driver_register+0x50/0x60
>> > [    2.122105]  fsl_dspi_driver_init+0x24/0x30
>> > [    2.126302]  do_one_initcall+0x54/0x2d0
>> > [    2.130149]  kernel_init_freeable+0x1ec/0x258
>> > [    2.134520]  kernel_init+0x1c/0x120
>> > [    2.138018]  ret_from_fork+0x10/0x34
>> > [    2.141606] Code: 97e0b11d aa0003f3 b4000680 f94006e0 (f9404000)
>> > [    2.147723] ---[ end trace 26cf63e6cbba33a8 ]---
>> > [    2.152374] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> > [    2.160061] SMP: stopping secondary CPUs
>> > [    2.163999] Kernel Offset: disabled
>> > [    2.167496] CPU features: 0x0040022,20006008
>> > [    2.171777] Memory Limit: none
>> > [    2.174840] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>> >
>> > This is because since this commit, the allocation of the drivers private
>> > data is done explicitly and in this case spi_alloc_master() won't set the
>> > correct pointer.
>> >
>> > Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
>> > Signed-off-by: Michael Walle <michael@walle.cc>
>> > ---
>> 
>> Sascha, how did you test commit 530b5affc675?
> 
> Hi,
> 
> I just hit it on my Vybrid systems as well. It fails on every boot, so
> I have doubts that it was actually tested. The fix was posted on 23rd
> and applied within a few hours... also no time for anyone else to test
> it.

Mhh, given the benefit of the doubt, I could imagine that the allocs 
align up in a way, that the pointer is valid afterwards, no?

>> 
>> >  drivers/spi/spi-fsl-dspi.c | 2 ++
>> >  1 file changed, 2 insertions(+)
>> >
>> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
>> > index a939618f5e47..dd80be987bf9 100644
>> > --- a/drivers/spi/spi-fsl-dspi.c
>> > +++ b/drivers/spi/spi-fsl-dspi.c
>> > @@ -1236,6 +1236,8 @@ static int dspi_probe(struct platform_device *pdev)
>> >       if (!ctlr)
>> >               return -ENOMEM;
>> >
>> > +     spi_controller_set_devdata(ctlr, dspi);
> 
> Michael,
> 
> How about moving here platform_set_drvdata(pdev, dspi) from the end of
> the probe to keep them close to each other?

Given that this patch has a fixes tag, I'd rather keep the changes to a 
minimum to avoid future conflicts.

OTOH I don't know if its better if the "move platform_set_drvdata()" is 
in a seperate patch, conflict-wise.

Any suggestions?

-michael

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Krzysztof Kozlowski]

On Mon, 28 Sep 2020 at 09:29, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > This is because since this commit, the allocation of the drivers private
> > > data is done explicitly and in this case spi_alloc_master() won't set the
> > > correct pointer.
> > >
> > > Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
> > > Signed-off-by: Michael Walle <michael@walle.cc>
> > > ---
> >
> > Sascha, how did you test commit 530b5affc675?
>
> Hi,
>
> I just hit it on my Vybrid systems as well. It fails on every boot, so
> I have doubts that it was actually tested. The fix was posted on 23rd
> and applied within a few hours... also no time for anyone else to test
> it.

The flow of this patch to mainline/RC reminds me what Sasha Levin was
saying here:
https://lwn.net/Articles/753329/
" - This means that -rc commits mostly end up replacing obvious bugs
with less obvious ones.
 - A merge window commit spent 50% more days, on average, in -next
than a -rc commit."

Best regards,
Krzysztof

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Krzysztof Kozlowski]

On Mon, 28 Sep 2020 at 01:28, Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Mon, Sep 28, 2020 at 12:43:36AM +0200, Michael Walle wrote:
> > Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
> > path") this driver causes a kernel oops:
> >
> > [    1.891065] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
> > [    1.899889] Mem abort info:
> > [    1.902692]   ESR = 0x96000004
> > [    1.905754]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [    1.911089]   SET = 0, FnV = 0
> > [    1.914156]   EA = 0, S1PTW = 0
> > [    1.917303] Data abort info:
> > [    1.920193]   ISV = 0, ISS = 0x00000004
> > [    1.924044]   CM = 0, WnR = 0
> > [    1.927022] [0000000000000080] user address but active_mm is swapper
> > [    1.933403] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > [    1.938995] Modules linked in:
> > [    1.942060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc6-next-20200925-00026-gae556cc74e28-dirty #94
> > [    1.951838] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
> > [    1.960135] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> > [    1.966168] pc : dspi_setup+0xc8/0x2e0
> > [    1.969926] lr : dspi_setup+0xbc/0x2e0
> > [    1.973684] sp : ffff80001139b930
> > [    1.977005] x29: ffff80001139b930 x28: ffff00207a5d2000
> > [    1.982338] x27: 0000000000000006 x26: ffff00207a44d410
> > [    1.987669] x25: ffff002079c08100 x24: ffff00207a5d2400
> > [    1.993000] x23: ffff00207a5d2600 x22: ffff800011169948
> > [    1.998332] x21: ffff800010cbcd20 x20: ffff00207a58a800
> > [    2.003663] x19: ffff00207a76b700 x18: 0000000000000010
> > [    2.008994] x17: 0000000000000001 x16: 0000000000000019
> > [    2.014326] x15: ffffffffffffffff x14: 0720072007200720
> > [    2.019657] x13: 0720072007200720 x12: ffff8000111fc5e0
> > [    2.024989] x11: 0000000000000003 x10: ffff8000111e45a0
> > [    2.030320] x9 : 0000000000000000 x8 : ffff00207a76b780
> > [    2.035651] x7 : 0000000000000000 x6 : 000000000000003f
> > [    2.040982] x5 : 0000000000000040 x4 : ffff80001139b918
> > [    2.046313] x3 : 0000000000000001 x2 : 64b62cc917af5100
> > [    2.051643] x1 : 0000000000000000 x0 : 0000000000000000
> > [    2.056973] Call trace:
> > [    2.059425]  dspi_setup+0xc8/0x2e0
> > [    2.062837]  spi_setup+0xcc/0x248
> > [    2.066160]  spi_add_device+0xb4/0x198
> > [    2.069918]  of_register_spi_device+0x250/0x370
> > [    2.074462]  spi_register_controller+0x4f4/0x770
> > [    2.079094]  dspi_probe+0x5bc/0x7b0
> > [    2.082594]  platform_drv_probe+0x5c/0xb0
> > [    2.086615]  really_probe+0xec/0x3c0
> > [    2.090200]  driver_probe_device+0x60/0xc0
> > [    2.094308]  device_driver_attach+0x7c/0x88
> > [    2.098503]  __driver_attach+0x60/0xe8
> > [    2.102263]  bus_for_each_dev+0x7c/0xd0
> > [    2.106109]  driver_attach+0x2c/0x38
> > [    2.109692]  bus_add_driver+0x194/0x1f8
> > [    2.113538]  driver_register+0x6c/0x128
> > [    2.117385]  __platform_driver_register+0x50/0x60
> > [    2.122105]  fsl_dspi_driver_init+0x24/0x30
> > [    2.126302]  do_one_initcall+0x54/0x2d0
> > [    2.130149]  kernel_init_freeable+0x1ec/0x258
> > [    2.134520]  kernel_init+0x1c/0x120
> > [    2.138018]  ret_from_fork+0x10/0x34
> > [    2.141606] Code: 97e0b11d aa0003f3 b4000680 f94006e0 (f9404000)
> > [    2.147723] ---[ end trace 26cf63e6cbba33a8 ]---
> > [    2.152374] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > [    2.160061] SMP: stopping secondary CPUs
> > [    2.163999] Kernel Offset: disabled
> > [    2.167496] CPU features: 0x0040022,20006008
> > [    2.171777] Memory Limit: none
> > [    2.174840] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> >
> > This is because since this commit, the allocation of the drivers private
> > data is done explicitly and in this case spi_alloc_master() won't set the
> > correct pointer.
> >
> > Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
> > Signed-off-by: Michael Walle <michael@walle.cc>
> > ---
>
> Sascha, how did you test commit 530b5affc675?

Hi,

I just hit it on my Vybrid systems as well. It fails on every boot, so
I have doubts that it was actually tested. The fix was posted on 23rd
and applied within a few hours... also no time for anyone else to test
it.

>
> >  drivers/spi/spi-fsl-dspi.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index a939618f5e47..dd80be987bf9 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -1236,6 +1236,8 @@ static int dspi_probe(struct platform_device *pdev)
> >       if (!ctlr)
> >               return -ENOMEM;
> >
> > +     spi_controller_set_devdata(ctlr, dspi);

Michael,

How about moving here platform_set_drvdata(pdev, dspi) from the end of
the probe to keep them close to each other?

Best regards,
Krzysztof


> > +
> >       dspi->pdev = pdev;
> >       dspi->ctlr = ctlr;
> >
> > --
> > 2.20.1
> >
>
> Thanks,
> -Vladimir

Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Vladimir Oltean]

On Mon, Sep 28, 2020 at 12:43:36AM +0200, Michael Walle wrote:
> Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
> path") this driver causes a kernel oops:
> 
> [    1.891065] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
> [    1.899889] Mem abort info:
> [    1.902692]   ESR = 0x96000004
> [    1.905754]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    1.911089]   SET = 0, FnV = 0
> [    1.914156]   EA = 0, S1PTW = 0
> [    1.917303] Data abort info:
> [    1.920193]   ISV = 0, ISS = 0x00000004
> [    1.924044]   CM = 0, WnR = 0
> [    1.927022] [0000000000000080] user address but active_mm is swapper
> [    1.933403] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [    1.938995] Modules linked in:
> [    1.942060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc6-next-20200925-00026-gae556cc74e28-dirty #94
> [    1.951838] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
> [    1.960135] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> [    1.966168] pc : dspi_setup+0xc8/0x2e0
> [    1.969926] lr : dspi_setup+0xbc/0x2e0
> [    1.973684] sp : ffff80001139b930
> [    1.977005] x29: ffff80001139b930 x28: ffff00207a5d2000
> [    1.982338] x27: 0000000000000006 x26: ffff00207a44d410
> [    1.987669] x25: ffff002079c08100 x24: ffff00207a5d2400
> [    1.993000] x23: ffff00207a5d2600 x22: ffff800011169948
> [    1.998332] x21: ffff800010cbcd20 x20: ffff00207a58a800
> [    2.003663] x19: ffff00207a76b700 x18: 0000000000000010
> [    2.008994] x17: 0000000000000001 x16: 0000000000000019
> [    2.014326] x15: ffffffffffffffff x14: 0720072007200720
> [    2.019657] x13: 0720072007200720 x12: ffff8000111fc5e0
> [    2.024989] x11: 0000000000000003 x10: ffff8000111e45a0
> [    2.030320] x9 : 0000000000000000 x8 : ffff00207a76b780
> [    2.035651] x7 : 0000000000000000 x6 : 000000000000003f
> [    2.040982] x5 : 0000000000000040 x4 : ffff80001139b918
> [    2.046313] x3 : 0000000000000001 x2 : 64b62cc917af5100
> [    2.051643] x1 : 0000000000000000 x0 : 0000000000000000
> [    2.056973] Call trace:
> [    2.059425]  dspi_setup+0xc8/0x2e0
> [    2.062837]  spi_setup+0xcc/0x248
> [    2.066160]  spi_add_device+0xb4/0x198
> [    2.069918]  of_register_spi_device+0x250/0x370
> [    2.074462]  spi_register_controller+0x4f4/0x770
> [    2.079094]  dspi_probe+0x5bc/0x7b0
> [    2.082594]  platform_drv_probe+0x5c/0xb0
> [    2.086615]  really_probe+0xec/0x3c0
> [    2.090200]  driver_probe_device+0x60/0xc0
> [    2.094308]  device_driver_attach+0x7c/0x88
> [    2.098503]  __driver_attach+0x60/0xe8
> [    2.102263]  bus_for_each_dev+0x7c/0xd0
> [    2.106109]  driver_attach+0x2c/0x38
> [    2.109692]  bus_add_driver+0x194/0x1f8
> [    2.113538]  driver_register+0x6c/0x128
> [    2.117385]  __platform_driver_register+0x50/0x60
> [    2.122105]  fsl_dspi_driver_init+0x24/0x30
> [    2.126302]  do_one_initcall+0x54/0x2d0
> [    2.130149]  kernel_init_freeable+0x1ec/0x258
> [    2.134520]  kernel_init+0x1c/0x120
> [    2.138018]  ret_from_fork+0x10/0x34
> [    2.141606] Code: 97e0b11d aa0003f3 b4000680 f94006e0 (f9404000)
> [    2.147723] ---[ end trace 26cf63e6cbba33a8 ]---
> [    2.152374] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [    2.160061] SMP: stopping secondary CPUs
> [    2.163999] Kernel Offset: disabled
> [    2.167496] CPU features: 0x0040022,20006008
> [    2.171777] Memory Limit: none
> [    2.174840] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> 
> This is because since this commit, the allocation of the drivers private
> data is done explicitly and in this case spi_alloc_master() won't set the
> correct pointer.
> 
> Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---

Sascha, how did you test commit 530b5affc675?

>  drivers/spi/spi-fsl-dspi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index a939618f5e47..dd80be987bf9 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -1236,6 +1236,8 @@ static int dspi_probe(struct platform_device *pdev)
>  	if (!ctlr)
>  		return -ENOMEM;
>  
> +	spi_controller_set_devdata(ctlr, dspi);
> +
>  	dspi->pdev = pdev;
>  	dspi->ctlr = ctlr;
>  
> -- 
> 2.20.1
> 

Thanks,
-Vladimir

[PATCH] spi: fsl-dspi: fix NULL pointer dereference

[Michael Walle]

Since commit 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove
path") this driver causes a kernel oops:

[    1.891065] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
[    1.899889] Mem abort info:
[    1.902692]   ESR = 0x96000004
[    1.905754]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.911089]   SET = 0, FnV = 0
[    1.914156]   EA = 0, S1PTW = 0
[    1.917303] Data abort info:
[    1.920193]   ISV = 0, ISS = 0x00000004
[    1.924044]   CM = 0, WnR = 0
[    1.927022] [0000000000000080] user address but active_mm is swapper
[    1.933403] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[    1.938995] Modules linked in:
[    1.942060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc6-next-20200925-00026-gae556cc74e28-dirty #94
[    1.951838] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
[    1.960135] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
[    1.966168] pc : dspi_setup+0xc8/0x2e0
[    1.969926] lr : dspi_setup+0xbc/0x2e0
[    1.973684] sp : ffff80001139b930
[    1.977005] x29: ffff80001139b930 x28: ffff00207a5d2000
[    1.982338] x27: 0000000000000006 x26: ffff00207a44d410
[    1.987669] x25: ffff002079c08100 x24: ffff00207a5d2400
[    1.993000] x23: ffff00207a5d2600 x22: ffff800011169948
[    1.998332] x21: ffff800010cbcd20 x20: ffff00207a58a800
[    2.003663] x19: ffff00207a76b700 x18: 0000000000000010
[    2.008994] x17: 0000000000000001 x16: 0000000000000019
[    2.014326] x15: ffffffffffffffff x14: 0720072007200720
[    2.019657] x13: 0720072007200720 x12: ffff8000111fc5e0
[    2.024989] x11: 0000000000000003 x10: ffff8000111e45a0
[    2.030320] x9 : 0000000000000000 x8 : ffff00207a76b780
[    2.035651] x7 : 0000000000000000 x6 : 000000000000003f
[    2.040982] x5 : 0000000000000040 x4 : ffff80001139b918
[    2.046313] x3 : 0000000000000001 x2 : 64b62cc917af5100
[    2.051643] x1 : 0000000000000000 x0 : 0000000000000000
[    2.056973] Call trace:
[    2.059425]  dspi_setup+0xc8/0x2e0
[    2.062837]  spi_setup+0xcc/0x248
[    2.066160]  spi_add_device+0xb4/0x198
[    2.069918]  of_register_spi_device+0x250/0x370
[    2.074462]  spi_register_controller+0x4f4/0x770
[    2.079094]  dspi_probe+0x5bc/0x7b0
[    2.082594]  platform_drv_probe+0x5c/0xb0
[    2.086615]  really_probe+0xec/0x3c0
[    2.090200]  driver_probe_device+0x60/0xc0
[    2.094308]  device_driver_attach+0x7c/0x88
[    2.098503]  __driver_attach+0x60/0xe8
[    2.102263]  bus_for_each_dev+0x7c/0xd0
[    2.106109]  driver_attach+0x2c/0x38
[    2.109692]  bus_add_driver+0x194/0x1f8
[    2.113538]  driver_register+0x6c/0x128
[    2.117385]  __platform_driver_register+0x50/0x60
[    2.122105]  fsl_dspi_driver_init+0x24/0x30
[    2.126302]  do_one_initcall+0x54/0x2d0
[    2.130149]  kernel_init_freeable+0x1ec/0x258
[    2.134520]  kernel_init+0x1c/0x120
[    2.138018]  ret_from_fork+0x10/0x34
[    2.141606] Code: 97e0b11d aa0003f3 b4000680 f94006e0 (f9404000)
[    2.147723] ---[ end trace 26cf63e6cbba33a8 ]---
[    2.152374] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    2.160061] SMP: stopping secondary CPUs
[    2.163999] Kernel Offset: disabled
[    2.167496] CPU features: 0x0040022,20006008
[    2.171777] Memory Limit: none
[    2.174840] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

This is because since this commit, the allocation of the drivers private
data is done explicitly and in this case spi_alloc_master() won't set the
correct pointer.

Fixes: 530b5affc675 ("spi: fsl-dspi: fix use-after-free in remove path")
Signed-off-by: Michael Walle <michael@walle.cc>
---
 drivers/spi/spi-fsl-dspi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index a939618f5e47..dd80be987bf9 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1236,6 +1236,8 @@ static int dspi_probe(struct platform_device *pdev)
 	if (!ctlr)
 		return -ENOMEM;
 
+	spi_controller_set_devdata(ctlr, dspi);
+
 	dspi->pdev = pdev;
 	dspi->ctlr = ctlr;
 
-- 
2.20.1