lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 9 Aug 2017 00:49:40 +0000
From:   Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
To:     Laurent <laurent.pinchart@...asonboard.com>,
        Anton Volkov <avolkov@...ras.ru>
Cc:     Linux-Kernel <linux-kernel@...r.kernel.org>,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        ldv-project@...uxtesting.org, dmaengine@...r.kernel.org,
        vinod.koul@...el.com, geert+renesas@...der.be,
        niklas.soderlund+renesas@...natech.se
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ