Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: m_can: pci: agregar m_can_class_free_dev() faltante en los métodos probe/remove En m_can_pci_remove() y la ruta de manejo de errores de m_can_pci_probe(), se debe llamar a m_can_class_free_dev() para liberar el recurso asignado por m_can_class_allocate_dev(), de lo contrario habrá una fuga de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se corrige el use after free al revertir la tabla de terminación Cuando se tienen varios destinos con tablas de terminación y fallo el segundo o posteriores, el controlador revierte el uso de las tablas de términos, pero no restablece la asignación en attr->dests[num_vport_dests].termtbl, en cuyo caso se produce un use after free al liberar la regla. Se soluciona restableciendo la asignación de termtbl a nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: e100: Se corrige el posible use after free en e100_xmit_prepare En e100_xmit_prepare(), si no podemos mapear el skb, entonces devolvemos -ENOMEM, por lo que e100_xmit_frame() devolverá NETDEV_TX_BUSY y la capa superior reenviará el skb. Pero el skb ya está liberado, lo que provocará un error UAF cuando la capa superior reenvíe el skb. Elimine la liberación dañina.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: Se ha corregido el manejo de errores en iavf_init_module(). iavf_init_module() no destruirá workqueue cuando falle pci_register_driver(). Se llama a destroy_workqueue() cuando falle pci_register_driver() para evitar la pérdida de recursos. Similar al manejo de u132_hcd_init en el commit f276e002793c ("usb: u132-hcd: fix resource leak")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ixgbevf: Se solucionó la pérdida de recursos en ixgbevf_init_module() ixgbevf_init_module() no destruirá la cola de trabajo creada por create_singlethread_workqueue() cuando pci_register_driver() falló. Agregue destroy_workqueue() en la ruta de error para evitar la pérdida de recursos. Similar al manejo de u132_hcd_init en el commit f276e002793c ("usb: u132-hcd: fix resource leak")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (ibmpex) Se corrige un posible UAF cuando fallo ibmpex_register_bmc() Advertencia de informe de Smatch de la siguiente manera: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' no se eliminó de la lista Si ibmpex_find_sensors() fallo en ibmpex_register_bmc(), se liberarán los datos, pero data->list no se eliminará de driver_data.bmc_data, entonces el recorrido de la lista puede causar UAF. Se soluciona eliminándolo de driver_data.bmc_data antes de free().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: libbpf: desbordamiento de tamaño del controlador para ringbuf mmap El tamaño máximo de ringbuf es de 2 GB en un host x86-64, por lo que 2 * max_entries desbordarán u32 al asignar la página del productor y las páginas de datos. Solo convertir max_entries a size_t no es suficiente, porque para la aplicación de 32 bits en un kernel de 64 bits, el tamaño de la región mmap de solo lectura también podría desbordar size_t. Entonces, arréglelo convirtiendo el tamaño de la región mmap de solo lectura en __u64 y verificando si habrá o no desbordamiento durante mmap.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: health: afe4403: Se corrige la lectura oob en el informe de KASAN afe4403_read_raw que indica que la lectura está fuera de los límites de la siguiente manera: ERROR: KASAN: global-out-of-bounds en afe4403_read_raw+0x42e/0x4c0 Lectura de tamaño 4 en la dirección ffffffffc02ac638 por la tarea cat/279 Seguimiento de llamadas: afe4403_read_raw iio_read_channel_info dev_attr_show La dirección con errores pertenece a la variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 Este problema se puede reproducir con un solo comando: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw El tamaño de la matriz de afe4403_channel_leds es menor que channels, por lo que el acceso con chan->address provoca una lectura OOB en afe4403_read_raw. Solucione el problema moviendo el acceso antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: health: afe4404: Se corrige la lectura oob en el informe de KASAN afe4404_[read|write]_raw de la siguiente manera: ERROR: KASAN: global-out-of-bounds en afe4404_read_raw+0x2ce/0x380 Lectura de tamaño 4 en la dirección ffffffffc00e4658 por la tarea cat/278 Rastreo de llamadas: afe4404_read_raw iio_read_channel_info dev_attr_show La dirección con errores pertenece a la variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 Este problema se puede reproducir con un solo comando: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw El tamaño de la matriz de afe4404_channel_leds y afe4404_channel_offdacs son menores que los canales, por lo que el acceso con chan->address provoca una lectura OOB en afe4404_[read|write]_raw. Solucione este problema moviendo el acceso antes de usarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: qgroup: corrección del error de suspensión desde un contexto no válido en btrfs_qgroup_inherit() Syzkaller informó de un ERROR como el siguiente: ERROR: función de suspensión llamada desde un contexto no válido en include/linux/sched/mm.h:274 Seguimiento de llamadas: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Solucione esto llamando a qgroup_dirty() en @dstqgroup y actualice el elemento de límite en btrfs_run_qgroups() más tarde fuera del contexto de spinlock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ops: Fix bounds check for _sx controls Para los controles _sx, la semántica del campo max no es la habitual, max es el número de pasos en lugar del valor máximo. Esto significa que nuestra comprobación en snd_soc_put_volsw_sx() solo debe comprobarse con el valor máximo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Búferes libres cuando se elimina un evento dinámico usado Después de que se hayan agregado y eliminado 65536 eventos dinámicos, el campo "tipo" del evento usa el primer número de tipo que está disponible (no usado actualmente por otros eventos). Un número de tipo es el identificador de los blobs binarios en el búfer de anillo de rastreo (conocidos como eventos) para mapearlos a la lógica que puede analizar el blob binario. El problema es que si se rastrea un evento dinámico (como un evento kprobe) y está en el búfer de anillo, y luego ese evento se elimina (porque es dinámico, lo que significa que se puede crear y destruir), si se crea otro evento dinámico que tenga el mismo número, se usará la lógica de ese nuevo evento al analizar el blob binario. Para mostrar cómo esto puede ser un problema, lo siguiente puede bloquear el kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; Para cada iteración de lo anterior, la escritura en kprobe_events eliminará el evento anterior y creará uno nuevo (con el mismo formato) y aumentará el número de tipo al siguiente disponible hasta que el número de tipo alcance más de 65535, que es el número máximo para el tipo de 16 bits. Después de que alcanza ese número, la lógica para asignar un nuevo número simplemente busca el siguiente número disponible. Cuando se elimina un evento dinámico, ese número está disponible para ser reutilizado por el próximo evento dinámico creado. Es decir, una vez que lo anterior alcanza el número máximo, el número asignado al evento en ese bucle seguirá siendo el mismo. Ahora, eso significa que eliminar un evento dinámico y crear otro reutilizará el número de tipo de eventos anteriores. Aquí es donde pueden suceder cosas malas. Después de que finaliza el bucle anterior, el evento kprobes/foo que lee el primer parámetro de la llamada a la función do_sys_openat2 como un entero. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat seguimiento cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Ahora si borramos el kprobe y creamos uno nuevo que lea una cadena: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events Y ahora podemos hacer el trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????? ????????????????????????????????????????????????????????????????" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????? ??????????????????????????????????????????????????????????????????" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????????? ??????????????????????????????????????????????????" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="????????????????????????????????????????? ---truncado---