linux-kernel - Re: Sometimes DVB broken with commit 6769a0b7ee0c3b

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:   Mon, 12 Jun 2023 17:10:06 +0200
From:   "Linux regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Linux regressions mailing list <regressions@...ts.linux.dev>,
        Hyunwoo Kim <imv4bel@...il.com>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Thomas Voegtle <tv@...96.de>, linux-kernel@...r.kernel.org
Subject: Re: Sometimes DVB broken with commit 6769a0b7ee0c3b

On 05.06.23 20:00, Mauro Carvalho Chehab wrote:
> Em Mon, 5 Jun 2023 12:44:43 +0200
> Thorsten Leemhuis <regressions@...mhuis.info> escreveu:
>> On 05.06.23 12:37, Mauro Carvalho Chehab wrote:
>>> Em Mon, 5 Jun 2023 11:38:49 +0200
>>> "Linux regression tracking (Thorsten Leemhuis)" <regressions@...mhuis.info> escreveu:
>>>>
>>>> On 30.05.23 13:12, Thomas Voegtle wrote:  
>>>>>
>>>>> I have the problem that sometimes my DVB card does not initialize
>>>>> properly booting Linux 6.4-rc4.
>>>>> This is not always, maybe in 3 out of 4 attempts.
>>>>> When this happens somehow you don't see anything special in dmesg, but
>>>>> the card just doesn't work.
>>>>>
>>>>> Reverting this helps:
>>>>> commit 6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f
>>>>[...]
>>>> Mauro: I wonder if this is something you or someone else has to look
>>>> into, as Hyunwoo Kim posted a few times per months to Linux lists, but
>>>> according  to a quick search on lore hasn't posted anything since ~two
>>>> months now. :-/  
>>>
>>> Yeah, I was slow applying this one, as I was afraid of it to cause
>>> troubles. The DVB frontend state machine is complex, and uses a
>>> semaphore to update its state. There was some past attempts of
>>> addressing some lifetime issues there that we ended needing to revert
>>> or not being applied, as the fix caused more harm than good.
>>> [...]  
>>
>> Thx for the update. That's unfortunate, but how it is sometimes. Which
>> leads to a follow-up question: is reverting the culprit temporarily an
>> option? Or did those old use-after-free problems became known to be a
>> problem we can't live with anymore for another few months?
> 
> Reverting the patch seems to be the way to proceed. Then, work on another
> way to address UAF. 
> 
> I'm not aware of dvb users complaining about troubles due to UAF, although 
> it seems that there's now a CVE for it. So, maybe someone complained against
> a distro Kernel, which caused the CVE to be opened.
> 
> So, while it is nice to have the lifetime issues fixed, last time I checked,
> the USB dvb-usb/dvb-usb-v2 have some logic that usually prevents it to cause 
> real issues during device removal, and unbinding DVB PCIe devices is 
> something that users don't do in practice.

Thx for the explanation and handling this. I noticed you posted a
revert, but it misses a fixes tag for the reverted commit and a Link: or
Closes: tag to the report. I think Linus would very much welcome at
least one of the latter in a situation like this (see [1] and [2]). I
would, too, as then regzbot would have noticed the patch posting. But
whatever, no big deal, let me tell regzbot about the latest progress
manually:

#regzbot monitor:
https://lore.kernel.org/all/20230609082238.3671398-1-mchehab@kernel.org/
#regzbot fix: Revert "media: dvb-core: Fix use-after-free on race
condition at dvb_frontend"

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

[1] for details, see:
https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/

[2] see Documentation/process/submitting-patches.rst
(http://docs.kernel.org/process/submitting-patches.html) and
Documentation/process/5.Posting.rst
(https://docs.kernel.org/process/5.Posting.html)

--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.