CVE-2022-50725
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
24/12/2025
Last modified:
29/12/2025
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init()<br />
<br />
KASAN reports a use-after-free:<br />
BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]<br />
Call Trace:<br />
...<br />
dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]<br />
vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge]<br />
platform_probe+0xb6/0x170<br />
...<br />
Allocated by task 1238:<br />
...<br />
dvb_register_device+0x1a7/0xa70 [dvb_core]<br />
dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]<br />
vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]<br />
...<br />
Freed by task 1238:<br />
dvb_register_device+0x6d2/0xa70 [dvb_core]<br />
dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]<br />
vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]<br />
...<br />
<br />
It is because the error handling in vidtv_bridge_dvb_init() is wrong.<br />
<br />
First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but<br />
goto fail_dmx(_dev): calls release functions again, which causes<br />
use-after-free.<br />
<br />
Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause<br />
out-of-bound when i finished its loop (i == NUM_FE). And the loop<br />
releasing is wrong, although now NUM_FE is 1 so it won&#39;t cause problem.<br />
<br />
Fix this by correctly releasing everything.
Impact
References to Advisories, Solutions, and Tools
- https://git.kernel.org/stable/c/0369af6fe33d4053899b121b32e91f870b2cf0ae
- https://git.kernel.org/stable/c/06398ce69571a43a8a0dd0f1bfe35d221f726a6a
- https://git.kernel.org/stable/c/8a204a0b4a0d105229735222c515759ea2b126c1
- https://git.kernel.org/stable/c/ba8d9405935097e296bcf7a942c3a01df0edb865
- https://git.kernel.org/stable/c/c290aa527fd832d278c6388a3ba53a9890fbd74a



