Re: [PATCH 6.3 136/286] media: dvb-core: Fix use-after-free on race condition at dvb_frontend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13.06.23 11:00, Stefan Lippers-Hollmann wrote:
> On 2023-06-13, Stefan Lippers-Hollmann wrote:
>> On 2023-06-07, Greg Kroah-Hartman wrote:
>>> From: Hyunwoo Kim <imv4bel@xxxxxxxxx>
>>>
>>> [ Upstream commit 6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f ]
>>>
>>> If the device node of dvb_frontend is open() and the device is
>>> disconnected, many kinds of UAFs may occur when calling close()
>>> on the device node.
>>>
>>> The root cause of this is that wake_up() for dvbdev->wait_queue
>>> is implemented in the dvb_frontend_release() function, but
>>> wait_event() is not implemented in the dvb_frontend_stop() function.
>>>
>>> So, implement wait_event() function in dvb_frontend_stop() and
>>> add 'remove_mutex' which prevents race condition for 'fe->exit'.
>>>
>>> [mchehab: fix a couple of checkpatch warnings and some mistakes at the error handling logic]
>>>
>>> Link: https://lore.kernel.org/linux-media/20221117045925.14297-2-imv4bel@xxxxxxxxx
>> [...]
>>
>> I'm noticing a regression relative to kernel v6.3.6 with this change
>> as part of kernel v6.3.7 on my ivy-bridge system running
>> Debian/unstable (amd64) with vdr 2.6.0-1.1[0] and two DVB cards
>> TeVii S480 V2.1 (DVB-S2, dw2102) and an Xbox One Digital TV Tuner
>> (DVB-T2, dvb_usb_dib0700). The systemd unit starting vdr just times
>> out and hangs forever, with vdr never coming up and also preventing
>> a clean system shutdown (hard reset required). Apart from the systemd
>> unit timing out, there don't really appear to be any further issues
>> logged.
> [...]
> 
> I've now also tested v6.4-rc6-26-gfb054096aea0 and can reproduce
> this regression there as well, with the same fix of reverting this
> corresponding patch.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f

Earlier report about problem due to 6769a0b7ee0c:
https://lore.kernel.org/all/da5382ad-09d6-20ac-0d53-611594b30861@xxxxxxxx/

Proposed revert:
https://lore.kernel.org/all/20230609082238.3671398-1-mchehab@xxxxxxxxxx/

Mauro, now that the patch made it into a stable tree, could you help
getting the revert quickly to Linus? Or shall we maybe ask him to pick
it up straight from the list?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
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.



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux