2017-08-08 12:09:44

by Anton Volkov

[permalink] [raw]
Subject: Possible null pointer dereference in rcar-dmac.ko

Hello.

While searching for races in the Linux kernel I've come across
"drivers/dma/sh/rcar-dmac.ko" module. Here is a question that I came up
with while analyzing results. Lines are given using the info from Linux
v4.12.

Consider the following case:

Thread 1: Thread 2:
rcar_dmac_probe
->rcar_dmac_chan_probe
(&dmac->channels[i])
rchan = &dmac->channels[i]
chan = &rchan->chan
devm_request_threaded_irq(rchan)
chan->device = &dmac->engine rcar_dmac_isr_channel
->rcar_dmac_isr_transfer_end(chan)
->rcar_dmac_chan_start_xfer(chan)
engine->dev = &pdev->dev; <READ chan->chan.device->dev>
(rcar-dmac.c: line 1828) (rcar-dmac.c: line 351)

As far as I understand engine->dev is NULL before its initialization in
probe. Thus there might be a NULL pointer dereference in
rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which
is equal to (&dmac->engine)->dev. Is this possible from your point of view?

Thank you for your time.

-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: [email protected]


2017-08-09 00:49:54

by Kuninori Morimoto

[permalink] [raw]
Subject: Re: Possible null pointer dereference in rcar-dmac.ko


Hi Anton

# add Laurent

> While searching for races in the Linux kernel I've come across
> "drivers/dma/sh/rcar-dmac.ko" module. Here is a question that I came
> up with while analyzing results. Lines are given using the info from
> Linux v4.12.
>
> Consider the following case:
>
> Thread 1: Thread 2:
> rcar_dmac_probe
> ->rcar_dmac_chan_probe
> (&dmac->channels[i])
> rchan = &dmac->channels[i]
> chan = &rchan->chan
> devm_request_threaded_irq(rchan)
> chan->device = &dmac->engine rcar_dmac_isr_channel
> ->rcar_dmac_isr_transfer_end(chan)
> ->rcar_dmac_chan_start_xfer(chan)
> engine->dev = &pdev->dev; <READ chan->chan.device->dev>
> (rcar-dmac.c: line 1828) (rcar-dmac.c: line 351)
>
> As far as I understand engine->dev is NULL before its initialization
> in probe. Thus there might be a NULL pointer dereference in
> rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which
> is equal to (&dmac->engine)->dev. Is this possible from your point of
> view?

Very rare case, but not impossible (?).
I think these engine->xxx initialize should be done before
of_dma_controller_register();
engine.channels is initialized independently somehow...

Best regards
---
Kuninori Morimoto

2017-08-09 07:58:15

by Laurent Pinchart

[permalink] [raw]
Subject: Re: Possible null pointer dereference in rcar-dmac.ko

Hello,

On Wednesday 09 Aug 2017 00:49:40 Kuninori Morimoto wrote:
> Hi Anton
>
> # add Laurent
>
> > While searching for races in the Linux kernel I've come across
> > "drivers/dma/sh/rcar-dmac.ko" module. Here is a question that I came
> > up with while analyzing results. Lines are given using the info from
> > Linux v4.12.
> >
> > Consider the following case:
> >
> > Thread 1: Thread 2:
> > rcar_dmac_probe
> > ->rcar_dmac_chan_probe
> >
> > (&dmac->channels[i])
> >
> > rchan = &dmac->channels[i]
> > chan = &rchan->chan
> > devm_request_threaded_irq(rchan)
> > chan->device = &dmac->engine rcar_dmac_isr_channel
> >
> > ->rcar_dmac_isr_transfer_end(chan)
> >
> > ->rcar_dmac_chan_start_xfer(chan)
> >
> > engine->dev = &pdev->dev; <READ chan->chan.device->dev>
> > (rcar-dmac.c: line 1828) (rcar-dmac.c: line 351)
> >
> > As far as I understand engine->dev is NULL before its initialization
> > in probe. Thus there might be a NULL pointer dereference in
> > rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which
> > is equal to (&dmac->engine)->dev. Is this possible from your point of
> > view?
>
> Very rare case, but not impossible (?).
> I think these engine->xxx initialize should be done before
> of_dma_controller_register();
> engine.channels is initialized independently somehow...

There should be no interrupt pending at the time the interrupt handler is
registered, but to be safe it's indeed a good practice to register the
interrupt handler after everything else has been initialized. Patches are
welcome :-)

--
Regards,

Laurent Pinchart

2017-08-10 02:09:36

by Kuninori Morimoto

[permalink] [raw]
Subject: Re: Possible null pointer dereference in rcar-dmac.ko

Anton Volkov noticed that engine->dev is NULL before
of_dma_controller_register() in probe.
Thus there might be a NULL pointer dereference in
rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which
is equal to (&dmac->engine)->dev.
To be more safety code, this patch initialize dmac->engine before it.

Reported-by: Anton Volkov <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
---
> Anton, Laurent

I created this patch because noone posted it yesterday.
Anton, you can use this patch and replace Author to you if you want.
Thus, I used [RFC] on this patch

drivers/dma/sh/rcar-dmac.c | 51 +++++++++++++++++++++++-----------------------
1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index ffcadca..6d60628 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1818,8 +1818,32 @@ static int rcar_dmac_probe(struct platform_device *pdev)
goto error;
}

- /* Initialize the channels. */
- INIT_LIST_HEAD(&dmac->engine.channels);
+ /* Initialize engine */
+ engine = &dmac->engine;
+
+ dma_cap_set(DMA_MEMCPY, engine->cap_mask);
+ dma_cap_set(DMA_SLAVE, engine->cap_mask);
+
+ engine->dev = &pdev->dev;
+ engine->copy_align = ilog2(RCAR_DMAC_MEMCPY_XFER_SIZE);
+
+ engine->src_addr_widths = widths;
+ engine->dst_addr_widths = widths;
+ engine->directions = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
+ engine->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+ engine->device_alloc_chan_resources = rcar_dmac_alloc_chan_resources;
+ engine->device_free_chan_resources = rcar_dmac_free_chan_resources;
+ engine->device_prep_dma_memcpy = rcar_dmac_prep_dma_memcpy;
+ engine->device_prep_slave_sg = rcar_dmac_prep_slave_sg;
+ engine->device_prep_dma_cyclic = rcar_dmac_prep_dma_cyclic;
+ engine->device_config = rcar_dmac_device_config;
+ engine->device_terminate_all = rcar_dmac_chan_terminate_all;
+ engine->device_tx_status = rcar_dmac_tx_status;
+ engine->device_issue_pending = rcar_dmac_issue_pending;
+ engine->device_synchronize = rcar_dmac_device_synchronize;
+
+ INIT_LIST_HEAD(&engine->channels);

for (i = 0; i < dmac->n_channels; ++i) {
ret = rcar_dmac_chan_probe(dmac, &dmac->channels[i],
@@ -1839,29 +1863,6 @@ static int rcar_dmac_probe(struct platform_device *pdev)
*
* Default transfer size of 32 bytes requires 32-byte alignment.
*/
- engine = &dmac->engine;
- dma_cap_set(DMA_MEMCPY, engine->cap_mask);
- dma_cap_set(DMA_SLAVE, engine->cap_mask);
-
- engine->dev = &pdev->dev;
- engine->copy_align = ilog2(RCAR_DMAC_MEMCPY_XFER_SIZE);
-
- engine->src_addr_widths = widths;
- engine->dst_addr_widths = widths;
- engine->directions = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
- engine->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
-
- engine->device_alloc_chan_resources = rcar_dmac_alloc_chan_resources;
- engine->device_free_chan_resources = rcar_dmac_free_chan_resources;
- engine->device_prep_dma_memcpy = rcar_dmac_prep_dma_memcpy;
- engine->device_prep_slave_sg = rcar_dmac_prep_slave_sg;
- engine->device_prep_dma_cyclic = rcar_dmac_prep_dma_cyclic;
- engine->device_config = rcar_dmac_device_config;
- engine->device_terminate_all = rcar_dmac_chan_terminate_all;
- engine->device_tx_status = rcar_dmac_tx_status;
- engine->device_issue_pending = rcar_dmac_issue_pending;
- engine->device_synchronize = rcar_dmac_device_synchronize;
-
ret = dma_async_device_register(engine);
if (ret < 0)
goto error;
--
1.9.1

2017-08-10 14:59:42

by Laurent Pinchart

[permalink] [raw]
Subject: Re: Possible null pointer dereference in rcar-dmac.ko

Hi Morimoto-san,

Thank you for the patch.

On Thursday 10 Aug 2017 02:09:21 Kuninori Morimoto wrote:
> Anton Volkov noticed that engine->dev is NULL before
> of_dma_controller_register() in probe.
> Thus there might be a NULL pointer dereference in
> rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which
> is equal to (&dmac->engine)->dev.
> To be more safety code, this patch initialize dmac->engine before it.
>
> Reported-by: Anton Volkov <[email protected]>
> Signed-off-by: Kuninori Morimoto <[email protected]>
> ---
>
> > Anton, Laurent
>
> I created this patch because noone posted it yesterday.
> Anton, you can use this patch and replace Author to you if you want.
> Thus, I used [RFC] on this patch

I don't think you have, the subject line is still "Re: Possible null pointer
dereference in rcar-dmac.ko" :-)

> drivers/dma/sh/rcar-dmac.c | 51 ++++++++++++++++++++-----------------------
> 1 file changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index ffcadca..6d60628 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1818,8 +1818,32 @@ static int rcar_dmac_probe(struct platform_device
> *pdev) goto error;
> }
>
> - /* Initialize the channels. */
> - INIT_LIST_HEAD(&dmac->engine.channels);
> + /* Initialize engine */
> + engine = &dmac->engine;
> +
> + dma_cap_set(DMA_MEMCPY, engine->cap_mask);
> + dma_cap_set(DMA_SLAVE, engine->cap_mask);
> +
> + engine->dev = &pdev->dev;
> + engine->copy_align = ilog2(RCAR_DMAC_MEMCPY_XFER_SIZE);
> +
> + engine->src_addr_widths = widths;
> + engine->dst_addr_widths = widths;
> + engine->directions = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
> + engine->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> +
> + engine->device_alloc_chan_resources =
rcar_dmac_alloc_chan_resources;
> + engine->device_free_chan_resources =
rcar_dmac_free_chan_resources;
> + engine->device_prep_dma_memcpy = rcar_dmac_prep_dma_memcpy;
> + engine->device_prep_slave_sg = rcar_dmac_prep_slave_sg;
> + engine->device_prep_dma_cyclic = rcar_dmac_prep_dma_cyclic;
> + engine->device_config = rcar_dmac_device_config;
> + engine->device_terminate_all =
rcar_dmac_chan_terminate_all;
> + engine->device_tx_status = rcar_dmac_tx_status;
> + engine->device_issue_pending = rcar_dmac_issue_pending;
> + engine->device_synchronize =
rcar_dmac_device_synchronize;
> +
> + INIT_LIST_HEAD(&engine->channels);

I don't think this fully fixes the problem, as the rcar_dmac_isr_error() IRQ
handler is still registered before all this. Furthermore, at least some of the
initialization at the end of rcar_dmac_chan_probe() has to be moved before the
rcar_dmac_isr_channel() IRQ handler registration.

Let's not commit a quick hack but fix the problem correctly, we should ensure
that all the initialization needed by IRQ handlers is performed before they
get registered.

> for (i = 0; i < dmac->n_channels; ++i) {
> ret = rcar_dmac_chan_probe(dmac, &dmac->channels[i],
> @@ -1839,29 +1863,6 @@ static int rcar_dmac_probe(struct platform_device
> *pdev) *
> * Default transfer size of 32 bytes requires 32-byte alignment.
> */
> - engine = &dmac->engine;
> - dma_cap_set(DMA_MEMCPY, engine->cap_mask);
> - dma_cap_set(DMA_SLAVE, engine->cap_mask);
> -
> - engine->dev = &pdev->dev;
> - engine->copy_align = ilog2(RCAR_DMAC_MEMCPY_XFER_SIZE);
> -
> - engine->src_addr_widths = widths;
> - engine->dst_addr_widths = widths;
> - engine->directions = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
> - engine->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> -
> - engine->device_alloc_chan_resources = rcar_dmac_alloc_chan_resources;
> - engine->device_free_chan_resources = rcar_dmac_free_chan_resources;
> - engine->device_prep_dma_memcpy = rcar_dmac_prep_dma_memcpy;
> - engine->device_prep_slave_sg = rcar_dmac_prep_slave_sg;
> - engine->device_prep_dma_cyclic = rcar_dmac_prep_dma_cyclic;
> - engine->device_config = rcar_dmac_device_config;
> - engine->device_terminate_all = rcar_dmac_chan_terminate_all;
> - engine->device_tx_status = rcar_dmac_tx_status;
> - engine->device_issue_pending = rcar_dmac_issue_pending;
> - engine->device_synchronize = rcar_dmac_device_synchronize;
> -
> ret = dma_async_device_register(engine);
> if (ret < 0)
> goto error;

--
Regards,

Laurent Pinchart

2017-08-21 06:15:23

by Kuninori Morimoto

[permalink] [raw]
Subject: Re: Possible null pointer dereference in rcar-dmac.ko


Hi Laurent

> I don't think this fully fixes the problem, as the rcar_dmac_isr_error() IRQ
> handler is still registered before all this. Furthermore, at least some of the
> initialization at the end of rcar_dmac_chan_probe() has to be moved before the
> rcar_dmac_isr_channel() IRQ handler registration.
>
> Let's not commit a quick hack but fix the problem correctly, we should ensure
> that all the initialization needed by IRQ handlers is performed before they
> get registered.

Yeah, indeed.
We need v2 patch

Best regards
---
Kuninori Morimoto