Vulnerabilidad en kernel de Linux (CVE-2024-50175)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: qcom: camss: Eliminar la protección use_count en stop_streaming La comprobación use_count se introdujo para que varias interfaces de datos sin procesar (RDI) simultáneas pudieran ser controladas por diferentes canales virtuales VC en la entrada CSIPHY que controlan la canalización de vídeo. Sin embargo, este es un uso inválido de use_count, ya que use_count pertenece a la cantidad de veces que una entidad de vídeo ha sido abierta por el espacio de usuario, no a la cantidad de transmisiones activas. Si use_count y stream-on count no coinciden, stop_streaming() se romperá, como es el caso actualmente y se ha hecho evidente al usar CAMSS con el softisp 0.3 lanzado por libcamera. El uso de use_count de esta manera es un poco chapucero y, en este momento, interrumpe el uso regular de CAMSS para un solo caso de transmisión. Detener qcam da como resultado el splat a continuación, y luego no se puede iniciar de nuevo y cualquier intento de hacerlo falla con -EBUSY. [ 1265.509831] ADVERTENCIA: CPU: 5 PID: 919 en drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common] ... [ 1265.510630] Rastreo de llamadas: [ 1265.510636] __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common] [ 1265.510648] vb2_core_streamoff+0x24/0xcc [videobuf2_common] [ 1265.510660] vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2] [ 1265.510673] v4l_streamoff+0x24/0x30 [videodev] [ 1265.510707] __video_do_ioctl+0x190/0x3f4 [videodev] [ 1265.510732] video_usercopy+0x304/0x8c4 [videodev] [ 1265.510757] video_ioctl2+0x18/0x34 [videodev] [ 1265.510782] v4l2_ioctl+0x40/0x60 [videodev] ... [ 1265.510944] videobuf2_common: error del controlador: la operación stop_streaming deja el búfer 0 en estado activo [ 1265.511175] videobuf2_common: error del controlador: la operación stop_streaming deja el búfer 1 en estado activo [ 1265.511398] videobuf2_common: error del controlador: la operación stop_streaming deja el buffer 2 en st activo Una forma específica de CAMSS para manejar múltiples VC en el mismo RDI podría ser: - Conteo de referencia de cada canalización habilitada para CSIPHY, CSID, VFE y RDIx. - Los búferes de video ya están asociados con msm_vfeN_rdiX, por lo que libera los búferes de video cuando stop_streaming te lo indica. - Solo libera los dominios de energía para CSIPHY, CSID y VFE cuando sus recuentos de referencia internos caen. De cualquier manera, negarse a liberar búferes de video según use_count es erróneo y debe revertirse. El código de habilitación de silicio para seleccionar VC está perfectamente bien. Es una "característica faltante conocida" que los VC simultáneos no funcionarán con CAMSS en este momento. Las pruebas iniciales con este código no mostraron ningún error, pero SoftISP y el uso "real" con Google Hangouts rompen el código ascendente con bastante rapidez. Necesitamos hacer una reversión parcial y volver a pasar por los VC. Esta confirmación revierte parcialmente el commit 89013969e232 ("media: camss: sm8250: Pipeline iniciando y deteniéndose para múltiples canales virtuales")