[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <0df6c6f5-c306-3e43-2b1f-013c47c51042@ispras.ru>
Date: Tue, 8 Aug 2017 15:09:39 +0300
From: Anton Volkov <avolkov@...ras.ru>
To: niklas.soderlund+renesas@...natech.se, geert+renesas@...der.be,
kuninori.morimoto.gx@...esas.com
Cc: vinod.koul@...el.com, dmaengine@...r.kernel.org,
linux-kernel@...r.kernel.org, ldv-project@...uxtesting.org,
Alexey Khoroshilov <khoroshilov@...ras.ru>
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: avolkov@...ras.ru
Powered by blists - more mailing lists