Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
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 0020
> [..]
> [ 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
On Mon, Nov 02, 2020 at 02:19:28AM +, 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
On Thu, Oct 30, 2020 at 21:18PM +0800, Vladimir Oltean
wrote:
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年10月30日 21:18
> To: Qiang Zhao
> Cc: broo...@kernel.org; linux-...@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
> >
> > 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 0020
> > [..]
> > [ 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
> > ---
>
> Reviewed-by: Vladimir Oltean
>
> 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
On Thu, Oct 30, 2020 at 21:02PM, Mark Brown wrote: > -Original Message- > From: Mark Brown > Sent: 2020年10月30日 21:02 > To: Qiang Zhao > Cc: olte...@gmail.com; linux-...@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 0020 > > [..] > > [ 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
On Thu, Oct 29, 2020 at 04:40:35PM +0800, Qiang Zhao wrote:
> From: Zhao Qiang
>
> 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 0020
> [..]
> [ 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
> ---
Reviewed-by: Vladimir Oltean
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
On Fri, Oct 30, 2020 at 02:04:06AM +, 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
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 0020 > [..] > [ 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. signature.asc Description: PGP signature
RE: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
On Thu, Oct 29, 2020 at 19:03PM, Vladimir Oltean wrote:
> -Original Message-
> From: Vladimir Oltean
> Sent: 2020年10月29日 19:03
> To: Qiang Zhao
> Cc: broo...@kernel.org; linux-...@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
> >
> > 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 0020
> > [..]
> > [ 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
> > ---
>
> Please update your tree.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
> om%2Ftorvalds%2Flinux%2Fcommit%2F6e3837668e00fb914ac2b43158ef51b0
> 27ec385cdata=04%7C01%7Cqiang.zhao%40nxp.com%7C50171bf65a5e
> 4f24e0c208d87bfa3fe9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C637395662023835048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sda
> ta=NlmOj1SfvKu2V7nrSYF3lDji25xbP5PeDl1PcwlKyr4%3Dreserved=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
On Thu, Oct 29, 2020 at 04:40:35PM +0800, Qiang Zhao wrote:
> From: Zhao Qiang
>
> 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 0020
> [..]
> [ 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
> ---
Please update your tree.
https://github.com/torvalds/linux/commit/6e3837668e00fb914ac2b43158ef51b027ec385c
Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
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 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 0080
> > > > [1.899889] Mem abort info:
> > > > [1.902692] ESR = 0x9604
> > > > [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 = 0x0004
> > > > [1.924044] CM = 0, WnR = 0
> > > > [1.927022] [0080] user address but active_mm is swapper
> > > > [1.933403] Internal error: Oops: 9604 [#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: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> > > > [1.966168] pc : dspi_setup+0xc8/0x2e0
> > > > [1.969926] lr : dspi_setup+0xbc/0x2e0
> > > > [1.973684] sp : 80001139b930
> > > > [1.977005] x29: 80001139b930 x28: 00207a5d2000
> > > > [1.982338] x27: 0006 x26: 00207a44d410
> > > > [1.987669] x25: 002079c08100 x24: 00207a5d2400
> > > > [1.993000] x23: 00207a5d2600 x22: 800011169948
> > > > [1.998332] x21: 800010cbcd20 x20: 00207a58a800
> > > > [2.003663] x19: 00207a76b700 x18: 0010
> > > > [2.008994] x17: 0001 x16: 0019
> > > > [2.014326] x15: x14: 0720072007200720
> > > > [2.019657] x13: 0720072007200720 x12: 8000111fc5e0
> > > > [2.024989] x11: 0003 x10: 8000111e45a0
> > > > [2.030320] x9 : x8 : 00207a76b780
> > > > [2.035651] x7 : x6 : 003f
> > > > [2.040982] x5 : 0040 x4 : 80001139b918
> > > > [2.046313] x3 : 0001 x2 : 64b62cc917af5100
> > > > [2.051643] x1 : x0 :
> > > > [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=0x000b
> > > > [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=0x000b ]---
> > > >
> > > > 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
> > > > ---
> > >
> > > 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
Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
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 0080
> > [1.899889] Mem abort info:
> > [1.902692] ESR = 0x9604
> > [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 = 0x0004
> > [1.924044] CM = 0, WnR = 0
> > [1.927022] [0080] user address but active_mm is swapper
> > [1.933403] Internal error: Oops: 9604 [#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: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> > [1.966168] pc : dspi_setup+0xc8/0x2e0
> > [1.969926] lr : dspi_setup+0xbc/0x2e0
> > [1.973684] sp : 80001139b930
> > [1.977005] x29: 80001139b930 x28: 00207a5d2000
> > [1.982338] x27: 0006 x26: 00207a44d410
> > [1.987669] x25: 002079c08100 x24: 00207a5d2400
> > [1.993000] x23: 00207a5d2600 x22: 800011169948
> > [1.998332] x21: 800010cbcd20 x20: 00207a58a800
> > [2.003663] x19: 00207a76b700 x18: 0010
> > [2.008994] x17: 0001 x16: 0019
> > [2.014326] x15: x14: 0720072007200720
> > [2.019657] x13: 0720072007200720 x12: 8000111fc5e0
> > [2.024989] x11: 0003 x10: 8000111e45a0
> > [2.030320] x9 : x8 : 00207a76b780
> > [2.035651] x7 : x6 : 003f
> > [2.040982] x5 : 0040 x4 : 80001139b918
> > [2.046313] x3 : 0001 x2 : 64b62cc917af5100
> > [2.051643] x1 : x0 :
> > [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=0x000b
> > [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=0x000b ]---
> >
> > 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
> > ---
>
> 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
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- |
Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
Am 2020-09-28 09:29, schrieb Krzysztof Kozlowski:
On Mon, 28 Sep 2020 at 01:28, 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 0080
> [1.899889] Mem abort info:
> [1.902692] ESR = 0x9604
> [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 = 0x0004
> [1.924044] CM = 0, WnR = 0
> [1.927022] [0080] user address but active_mm is swapper
> [1.933403] Internal error: Oops: 9604 [#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: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> [1.966168] pc : dspi_setup+0xc8/0x2e0
> [1.969926] lr : dspi_setup+0xbc/0x2e0
> [1.973684] sp : 80001139b930
> [1.977005] x29: 80001139b930 x28: 00207a5d2000
> [1.982338] x27: 0006 x26: 00207a44d410
> [1.987669] x25: 002079c08100 x24: 00207a5d2400
> [1.993000] x23: 00207a5d2600 x22: 800011169948
> [1.998332] x21: 800010cbcd20 x20: 00207a58a800
> [2.003663] x19: 00207a76b700 x18: 0010
> [2.008994] x17: 0001 x16: 0019
> [2.014326] x15: x14: 0720072007200720
> [2.019657] x13: 0720072007200720 x12: 8000111fc5e0
> [2.024989] x11: 0003 x10: 8000111e45a0
> [2.030320] x9 : x8 : 00207a76b780
> [2.035651] x7 : x6 : 003f
> [2.040982] x5 : 0040 x4 : 80001139b918
> [2.046313] x3 : 0001 x2 : 64b62cc917af5100
> [2.051643] x1 : x0 :
> [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=0x000b
> [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=0x000b ]---
>
> 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
> ---
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
Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
On Mon, 28 Sep 2020 at 09:29, Krzysztof Kozlowski 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
> > > ---
> >
> > 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
On Mon, 28 Sep 2020 at 01:28, 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 0080
> > [1.899889] Mem abort info:
> > [1.902692] ESR = 0x9604
> > [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 = 0x0004
> > [1.924044] CM = 0, WnR = 0
> > [1.927022] [0080] user address but active_mm is swapper
> > [1.933403] Internal error: Oops: 9604 [#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: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> > [1.966168] pc : dspi_setup+0xc8/0x2e0
> > [1.969926] lr : dspi_setup+0xbc/0x2e0
> > [1.973684] sp : 80001139b930
> > [1.977005] x29: 80001139b930 x28: 00207a5d2000
> > [1.982338] x27: 0006 x26: 00207a44d410
> > [1.987669] x25: 002079c08100 x24: 00207a5d2400
> > [1.993000] x23: 00207a5d2600 x22: 800011169948
> > [1.998332] x21: 800010cbcd20 x20: 00207a58a800
> > [2.003663] x19: 00207a76b700 x18: 0010
> > [2.008994] x17: 0001 x16: 0019
> > [2.014326] x15: x14: 0720072007200720
> > [2.019657] x13: 0720072007200720 x12: 8000111fc5e0
> > [2.024989] x11: 0003 x10: 8000111e45a0
> > [2.030320] x9 : x8 : 00207a76b780
> > [2.035651] x7 : x6 : 003f
> > [2.040982] x5 : 0040 x4 : 80001139b918
> > [2.046313] x3 : 0001 x2 : 64b62cc917af5100
> > [2.051643] x1 : x0 :
> > [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=0x000b
> > [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=0x000b ]---
> >
> > 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
> > ---
>
> 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
> > +
> >
Re: [PATCH] spi: fsl-dspi: fix NULL pointer dereference
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 0080
> [1.899889] Mem abort info:
> [1.902692] ESR = 0x9604
> [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 = 0x0004
> [1.924044] CM = 0, WnR = 0
> [1.927022] [0080] user address but active_mm is swapper
> [1.933403] Internal error: Oops: 9604 [#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: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> [1.966168] pc : dspi_setup+0xc8/0x2e0
> [1.969926] lr : dspi_setup+0xbc/0x2e0
> [1.973684] sp : 80001139b930
> [1.977005] x29: 80001139b930 x28: 00207a5d2000
> [1.982338] x27: 0006 x26: 00207a44d410
> [1.987669] x25: 002079c08100 x24: 00207a5d2400
> [1.993000] x23: 00207a5d2600 x22: 800011169948
> [1.998332] x21: 800010cbcd20 x20: 00207a58a800
> [2.003663] x19: 00207a76b700 x18: 0010
> [2.008994] x17: 0001 x16: 0019
> [2.014326] x15: x14: 0720072007200720
> [2.019657] x13: 0720072007200720 x12: 8000111fc5e0
> [2.024989] x11: 0003 x10: 8000111e45a0
> [2.030320] x9 : x8 : 00207a76b780
> [2.035651] x7 : x6 : 003f
> [2.040982] x5 : 0040 x4 : 80001139b918
> [2.046313] x3 : 0001 x2 : 64b62cc917af5100
> [2.051643] x1 : x0 :
> [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=0x000b
> [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=0x000b ]---
>
> 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
> ---
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
