linux-kernel - Re: [RFC PATCH v7 6/9] media: tegra: Add Tegra210 Video input driver

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: <c95cd2b6-8036-8c0a-25f3-6ea3fe35334a@nvidia.com>
Date:   Wed, 15 Apr 2020 16:28:42 -0700
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>
CC:     <thierry.reding@...il.com>, <jonathanh@...dia.com>,
        <frankc@...dia.com>, <hverkuil@...all.nl>, <sakari.ailus@....fi>,
        <helen.koike@...labora.com>, <sboyd@...nel.org>,
        <linux-media@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-clk@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v7 6/9] media: tegra: Add Tegra210 Video input driver

Sorry please ignore.

We can't free vi during v4l2 device release as when no device nodes are 
opened, vi free happens right away during host1x_video_remove.

With this tegra-video driver unbind ->bind will not work as vi memory 
allocated during vi_probe gets freed during v4l2 device release so 
during bind init() callback execution will crash as vi got freed while 
vi driver is still bound to device.

Will wait for Hans/Thierry comments as I see dependency depending on 
where unbind/bind happens.


On 4/15/20 4:08 PM, Sowjanya Komatineni wrote:
> With minor change of not using vi reference after 
> host1x_client_unregister and freeing vi during v4l2 device release works.
>
> For csi, we can use devm_kzalloc for now untill we decide later if we 
> want to expose async subdev nodes during sensor support.
>
> Will have this fix in v8 with a comment in vi_remove to make sure not 
> to use vi reference after host1x_client_unregister.
>
> Will test more and will release v8 with above fix to allow direct 
> host1x client driver unbind.
>
> Thanks
>
> sowjanya
>
>
> On 4/15/20 12:51 PM, Sowjanya Komatineni wrote:
>>
>> On 4/15/20 12:21 PM, Dmitry Osipenko wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> 15.04.2020 21:53, Sowjanya Komatineni пишет:
>>> ...
>>>>>>>>>> Have you tried to test this driver under KASAN? I suspect that
>>>>>>>>>> you just
>>>>>>>>>> masked the problem, instead of fixing it.
>>>> Tested with kmemleak scan and did not see any memory leaks
>>> You should get use-after-free and not memleak.
>> I don't see use-after-free bugs during the testing.
>>
>> But as mentioned when direct vi/csi client driver unbind happens 
>> while video device node is kept opened, vi driver remove will free vi 
>> structure memory but actual video device memory which is part of 
>> channels remains but list head gets lost when vi structure is freed.
>>
>> So, when device node is released and executes release callback as 
>> list head is lost it can't free allocated channels which is not good.
>>
>> This happens only with direct host1x client vi/csi driver unbind.
>>
>> Need to find better place to free host1x client driver data structure 
>> to allow direct client driver unbind->bind.
>>