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&amp;#39;t cause problem.<br /> <br /> Fix this by correctly releasing everything.

Impact