linux-kernel - Re: [PATCH v4 01/14] dmaengine: tegra-apb: Fix use-after-free

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]

Message-ID: <1327bb21-0364-da26-e6ed-ff6c19df03e6@gmail.com>
Date:   Tue, 14 Jan 2020 23:33:40 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Jon Hunter <jonathanh@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Vinod Koul <vkoul@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     dmaengine@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 01/14] dmaengine: tegra-apb: Fix use-after-free

14.01.2020 18:09, Jon Hunter пишет:
> 
> On 12/01/2020 17:29, Dmitry Osipenko wrote:
>> I was doing some experiments with I2C and noticed that Tegra APB DMA
>> driver crashes sometime after I2C DMA transfer termination. The crash
>> happens because tegra_dma_terminate_all() bails out immediately if pending
>> list is empty, thus it doesn't release the half-completed descriptors
>> which are getting re-used before ISR tasklet kicks-in.
> 
> Can you elaborate a bit more on how these are getting re-used? What is
> the sequence of events which results in the panic? I believe that this
> was also reported in the past [0] and so I don't doubt there is an issue
> here, but would like to completely understand this.
> 
> Thanks!
> Jon
> 
> [0] https://lore.kernel.org/patchwork/patch/675349/
> 

In my case it happens in the touchscreen driver during of the
touchscreen's interrupt handling (in a threaded IRQ handler) + CPU is
under load and there is other interrupts activity. So what happens here
is that the TS driver issues one I2C transfer, which fails with
(apparently bogus) timeout (because DMA descriptor is completed and
removed from the pending list, but tasklet not executed yet), and then
TS immediately issues another I2C transfer that re-uses the
yet-incompleted descriptor. That's my understanding.