* Possible null pointer dereference in rcar-dmac.ko
@ 2017-08-08 12:09 Anton Volkov
2017-08-09 0:49 ` Kuninori Morimoto
0 siblings, 1 reply; 6+ messages in thread
From: Anton Volkov @ 2017-08-08 12:09 UTC (permalink / raw)
To: niklas.soderlund+renesas, geert+renesas, kuninori.morimoto.gx
Cc: vinod.koul, dmaengine, linux-kernel, ldv-project,
Alexey Khoroshilov
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: avolkov@ispras.ru
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Possible null pointer dereference in rcar-dmac.ko 2017-08-08 12:09 Possible null pointer dereference in rcar-dmac.ko Anton Volkov @ 2017-08-09 0:49 ` Kuninori Morimoto 2017-08-09 7:58 ` Laurent Pinchart 0 siblings, 1 reply; 6+ messages in thread From: Kuninori Morimoto @ 2017-08-09 0:49 UTC (permalink / raw) To: Laurent, Anton Volkov Cc: Linux-Kernel, Alexey Khoroshilov, ldv-project, dmaengine, vinod.koul, geert+renesas, niklas.soderlund+renesas 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Possible null pointer dereference in rcar-dmac.ko 2017-08-09 0:49 ` Kuninori Morimoto @ 2017-08-09 7:58 ` Laurent Pinchart 2017-08-10 2:09 ` Kuninori Morimoto 0 siblings, 1 reply; 6+ messages in thread From: Laurent Pinchart @ 2017-08-09 7:58 UTC (permalink / raw) To: Kuninori Morimoto Cc: Anton Volkov, Linux-Kernel, Alexey Khoroshilov, ldv-project, dmaengine, vinod.koul, geert+renesas, niklas.soderlund+renesas 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Possible null pointer dereference in rcar-dmac.ko 2017-08-09 7:58 ` Laurent Pinchart @ 2017-08-10 2:09 ` Kuninori Morimoto 2017-08-10 14:59 ` Laurent Pinchart 0 siblings, 1 reply; 6+ messages in thread From: Kuninori Morimoto @ 2017-08-10 2:09 UTC (permalink / raw) To: Vinod Koul, Niklas Söderlund, Laurent, Dan Williams Cc: Linux-Renesas, Linux-Kernel, Arnd Bergmann, Anton Volkov, Alexey Khoroshilov, ldv-project, dmaengine, geert+renesas 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 <avolkov@ispras.ru> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> --- > 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Possible null pointer dereference in rcar-dmac.ko 2017-08-10 2:09 ` Kuninori Morimoto @ 2017-08-10 14:59 ` Laurent Pinchart 2017-08-21 6:15 ` Kuninori Morimoto 0 siblings, 1 reply; 6+ messages in thread From: Laurent Pinchart @ 2017-08-10 14:59 UTC (permalink / raw) To: Kuninori Morimoto Cc: Vinod Koul, Niklas Söderlund, Dan Williams, Linux-Renesas, Linux-Kernel, Arnd Bergmann, Anton Volkov, Alexey Khoroshilov, ldv-project, dmaengine, geert+renesas 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 <avolkov@ispras.ru> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > --- > > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Possible null pointer dereference in rcar-dmac.ko 2017-08-10 14:59 ` Laurent Pinchart @ 2017-08-21 6:15 ` Kuninori Morimoto 0 siblings, 0 replies; 6+ messages in thread From: Kuninori Morimoto @ 2017-08-21 6:15 UTC (permalink / raw) To: Laurent Pinchart Cc: Vinod Koul, Niklas Söderlund, Dan Williams, Linux-Renesas, Linux-Kernel, Arnd Bergmann, Anton Volkov, Alexey Khoroshilov, ldv-project, dmaengine, geert+renesas 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-08-21 6:15 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-08-08 12:09 Possible null pointer dereference in rcar-dmac.ko Anton Volkov 2017-08-09 0:49 ` Kuninori Morimoto 2017-08-09 7:58 ` Laurent Pinchart 2017-08-10 2:09 ` Kuninori Morimoto 2017-08-10 14:59 ` Laurent Pinchart 2017-08-21 6:15 ` Kuninori Morimoto
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox