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, 5 Jun 2023 19:00:46 +0100
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     Thorsten Leemhuis <regressions@...mhuis.info>
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

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:
> >   
> >> Hi, Thorsten here, the Linux kernel's regression tracker.
> >>
> >> 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
> >>> Author: Hyunwoo Kim <imv4bel@...il.com>
> >>> Date:   Thu Nov 17 04:59:22 2022 +0000
> >>>
> >>>     media: dvb-core: Fix use-after-free on race condition at dvb_frontend
> >>>
> >>>
> >>> I have:
> >>> 03:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
> >>> CX23887/8
> >>> PCIe Broadcast Audio and Video Decoder with 3D Comb [14f1:8880] (rev 04)
> >>>         Subsystem: Hauppauge computer works Inc. Device [0070:c138]
> >>>         Kernel driver in use: cx23885    
> >>
> >> Hmmm, that was posted last Tuesday and received not a single reply. :-/
> >>
> >> Hyunwoo Kim: could you please look at it, as it's a regression caused by
> >> a commit of yours (one that would be good to solve before 6.4 is
> >> finalized!)? And in case you are unable to do so let us know?
> >>
> >> But FWIW:
> >>
> >> 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.

Regards,
Mauro