Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1706457 > unrolled thread

Possible null pointer dereference in rcar-dmac.ko

Back to article view | Back to linux.kernel

Contents

  Possible null pointer dereference in rcar-dmac.ko Anton Volkov <avolkov@ispras.ru> - 2017-08-08 14:10 +0200
    Re: Possible null pointer dereference in rcar-dmac.ko Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-08-09 10:00 +0200
      Re: Possible null pointer dereference in rcar-dmac.ko Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-08-10 17:00 +0200

#1706457 — 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: avolkov@ispras.ru

[toc] | [next] | [standalone]

#1707114

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

[toc] | [prev] | [next] | [standalone]

#1708700

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web