CVE-2022-50369

In the Linux kernel, the following vulnerability has been resolved:

drm/vkms: Fix null-ptr-deref in vkms_release()

A null-ptr-deref is triggered when it tries to destroy the workqueue in vkms->output.composerworkq in vkmsrelease().

KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24 RIP: 0010:destroyworkqueue+0x2f/0x710 ... Call Trace: <TASK> ? vkmsconfigdebugfsinit+0x50/0x50 [vkms] _devmdrmdevalloc+0x15a/0x1c0 [drm] vkmsinit+0x245/0x1000 [vkms] dooneinitcall+0xd0/0x4f0 doinitmodule+0x1a4/0x680 loadmodule+0x6249/0x7110 _dosysfinitmodule+0x140/0x200 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0

The reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below:

vkmsinit() vkmscreate() devmdrmdevalloc() _devmdrmdevalloc() devmdrmdevinit() devmaddactionorreset() devmaddaction() # an error happened devmdrmdevinitrelease() drmdevput() krefput() drmdevrelease() vkmsrelease() destroyworkqueue() # null-ptr-deref happened vkmsmodesetinit() vkmsoutputinit() vkmscrtc_init() # where the workqueue get allocated

Fix this by checking if composerworkq is NULL before passing it to the destroyworkqueue() in vkms_release().