CVE-2021-47583

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: mxl111sf: cambiar la ubicación de mutex_init() Syzbot informó que mxl111sf_ctrl_msg() usa un mutex no inicializado. El problema estaba en la ubicación mutex_init() incorrecta. La llamada anterior a mutex_init(&state->msg_lock) estaba en la función ->init(), pero dvb_usbv2_init() tiene este orden de llamadas: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init() Desde Los dispositivos mxl111sf_* llaman a mxl111sf_ctrl_msg() en ->frontend_attach() internamente, necesitamos inicializar state->msg_lock antes de frontend_attach(). Para lograrlo, se agrega la llamada ->probe() a todos los dispositivos mxl111sf_*, lo que simplemente iniciará el mutex.

In the Linux kernel, the following vulnerability has been resolved: media: mxl111sf: change mutex_init() location Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized mutex. The problem was in wrong mutex_init() location. Previous mutex_init(&state->msg_lock) call was in ->init() function, but dvb_usbv2_init() has this order of calls: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init() Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach() internally we need to initialize state->msg_lock before frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_* devices, which will simply initiaize mutex.