From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752563AbdHIH6P (ORCPT ); Wed, 9 Aug 2017 03:58:15 -0400 Received: from galahad.ideasonboard.com ([185.26.127.97]:51874 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752199AbdHIH6N (ORCPT ); Wed, 9 Aug 2017 03:58:13 -0400 From: Laurent Pinchart To: Kuninori Morimoto Cc: Anton Volkov , Linux-Kernel , Alexey Khoroshilov , ldv-project@linuxtesting.org, dmaengine@vger.kernel.org, vinod.koul@intel.com, geert+renesas@glider.be, niklas.soderlund+renesas@ragnatech.se Subject: Re: Possible null pointer dereference in rcar-dmac.ko Date: Wed, 09 Aug 2017 10:58:28 +0300 Message-ID: <1966479.zaHQfZ4vb1@avalon> User-Agent: KMail/4.14.10 (Linux/4.9.34-gentoo; KDE/4.14.32; x86_64; ; ) In-Reply-To: <871solfu5n.wl%kuninori.morimoto.gx@renesas.com> References: <0df6c6f5-c306-3e43-2b1f-013c47c51042@ispras.ru> <871solfu5n.wl%kuninori.morimoto.gx@renesas.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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; 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