Vulnerabilidades

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---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige la desreferencia de puntero NULL en nilfs_palloc_commit_free_entry() Syzbot informó un error de desreferencia de puntero nulo: NILFS (loop0): segctord iniciando. Intervalo de construcción = 5 segundos, frecuencia de CP < 30 segundos. fallo de protección general, probablemente para dirección no canónica 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en rango [0x000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord No contaminado 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Código: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 ser a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc00000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 00000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Seguimiento de llamadas: nilfs_dat_commit_free fs/nilfs2/dat.c:114 [en línea] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [en línea] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [en línea] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [en línea] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [en línea] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [en línea] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 ... Si el archivo de metadatos DAT está dañado en el disco, existe un caso en el que req->pr_desc_bh es NULL y blocknr es 0 en nilfs_dat_commit_end() durante una operación de árbol b que actualiza en cascada los nodos ancestros del árbol b, porque nilfs_dat_commit_alloc() para un bloque de nivel inferior puede inicializar el blocknr en la misma entrada DAT entre nilfs_dat_prepare_end() y nilfs_dat_commit_end(). Si esto sucede, nilfs_dat_commit_end() llama a nilfs_dat_commit_free() sin encabezados de búfer válidos en req->pr_desc_bh y req->pr_bitmap_bh, y provoca la desreferencia del puntero NULL anterior en la función nilfs_palloc_commit_free_entry(), lo que provoca un bloqueo. Solucione este problema agregando una comprobación NULL en req->pr_desc_bh y req->pr_bitmap_bh antes de nilfs_palloc_commit_free_entry() en nilfs_dat_commit_free(). Esto también llama a nilfs_error() en ese caso para notificar que hay un fallo fatal en los metadatos del sistema de archivos y evitar operaciones futuras.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: can327: can327_feed_frame_to_netdev(): corrige una posible fuga de skb cuando netdev está inactivo En can327_feed_frame_to_netdev(), no liberaba el skb cuando netdev estaba inactivo, y todos los que llamaban a can327_feed_frame_to_netdev() tampoco liberaban el skb asignado. Eso desencadenaría una fuga de skb. Arréglelo añadiendo kfree_skb() en can327_feed_frame_to_netdev() cuando netdev esté inactivo. No probado, solo compilado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (asus-ec-sensors) Agregar comprobaciones para devm_kcalloc Como devm_kcalloc puede devolver NULL, se debe comprobar el valor de retorno para evitar la desreferencia del puntero NULL.