Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: i2c: ar0521: Usar la versión cansleep de gpiod_set_value() Si usamos el restablecimiento de GPIO desde el expansor de puerto I2C, debemos usar la variante *_cansleep() de las funciones GPIO. Esto no se hacía en las funciones ar0521_power_on()/ar0521_power_off(). Vamos a solucionarlo. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 11 en drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Módulos vinculados en: CPU: 0 PID: 11 Comm: kworker/u16:0 No contaminado 6.10.0 #53 Nombre del hardware: Diasom DS-RK3568-SOM-EVB (DT) Cola de trabajo: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9: ffffff8001d7a9f0 x8: ffffff8001d92570 x7: ffffff80efeeac80 x6: 000000003fc6e780 x5: ffffff8001d91c80 x4: 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Rastreo de llamadas: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: comprobar el retorno nulo de ACPI_ALLOCATE_ZEROED() en acpi_db_convert_to_package() Confirmación de ACPICA 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() puede fallar, los elementos pueden ser NULL y causarán una desreferencia de puntero NULL más adelante. [ rjw: Ediciones de asunto y registro de cambios ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mailbox: bcm2835: Fix timeout during suspend mode Durante la fase de suspensión de noirq, el controlador de energía de Raspberry Pi sufre tiempos de espera de propiedad de firmware. La razón es que la IRQ del buzón BCM2835 subyacente está deshabilitada y rpi_firmware_property_list() siempre se encontrará con un tiempo de espera [1]. Dado que el lado de VideoCore no se considera una fuente de reactivación, configure el indicador IRQF_NO_SUSPEND para el IRQ del buzón para mantenerlo habilitado durante el ciclo de suspensión-reanudación. [1] PM: suspensión tardía de dispositivos completada después de 1,754 msegs ADVERTENCIA: CPU: 0 PID: 438 en drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Tiempo de espera de transacción de firmware 0x00028001 Módulos vinculados: CPU: 0 PID: 438 Comm: bash Tainted: GC 6.9.3-dirty #17 Nombre del hardware: BCM2835 Rastreo de llamadas: unwind_backtrace de show_stack+0x18/0x1c show_stack de dump_stack_lvl+0x34/0x44 dump_stack_lvl de __warn+0x88/0xec __warn de warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt de rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list de rpi_firmware_property+0x68/0x8c rpi_firmware_property de rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power de _genpd_power_off+0xe4/0x148 _genpd_power_off de genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off de genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend de dpm_run_callback+0x78/0xd0 dpm_run_callback de device_suspend_noirq+0xc0/0x238 device_suspend_noirq de dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq desde suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter desde pm_suspend+0x254/0x2e4 pm_suspend desde state_store+0xa8/0xd4 state_store desde kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter desde vfs_write+0x12c/0x184 vfs_write desde ksys_write+0x78/0xc0 ksys_write desde ret_fast_syscall+0x0/0x54 Pila de excepciones (0xcc93dfa8 a 0xcc93dff0) [...] PM: suspensión noirq de dispositivos completada después de 3095,584 mseg

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: eliminar el desbloqueo irrazonable en ocfs2_read_blocks Serie de parches "Correcciones varias para ocfs2_read_blocks", v5. Esta serie contiene 2 correcciones para ocfs2_read_blocks(). El primer parche corrige el problema informado por syzbot, que detecta un balance de desbloqueo incorrecto en ocfs2_read_blocks(). El segundo parche corrige un problema informado por Heming Zhao al revisar la corrección anterior. Este parche (de 2): Hubo una liberación de bloqueo antes de salir, así que elimine el desbloqueo irrazonable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: cancelar dqi_sync_work antes de liberar oinfo ocfs2_global_read_info() inicializará y programará dqi_sync_work al final, si ocurre un error después de leer exitosamente la cuota global, activará la siguiente advertencia con CONFIG_DEBUG_OBJECTS_* habilitado: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c Esto informa que hay un trabajo retrasado activo al liberar oinfo en el manejo de errores, así que cancele dqi_sync_work primero. POR CIERTO, devuelva el estado en lugar de -1 cuando .read_file_info falle.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrección de índice fuera de los límites en transformación de color DCN30 Esta confirmación aborda un posible problema de índice fuera de los límites en la función `cm3_helper_translate_curve_to_hw_format` en el módulo de administración de color DCN30. El problema podría ocurrir cuando el índice 'i' excede la cantidad de puntos de función de transferencia (TRANSFER_FUNC_POINTS). La corrección agrega una verificación para garantizar que 'i' esté dentro de los límites antes de acceder a los puntos de función de transferencia. Si 'i' está fuera de los límites, la función devuelve falso para indicar un error. cm3_helper_translate_curve_to_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: desbordamiento de búfer 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 Error de cm3_helper_translate_curve_to_hw_format(): desbordamiento de búfer 'output_tf->tf_pts.blue' 1025 <= s32max

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/ncsi: deshabilitar la función work de ncsi antes de liberar la estructura asociada. La función work puede ejecutarse después de que se libera el dispositivo ncsi, lo que genera errores de use after free o pánico del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: prueba de que csum_start no sea demasiado pequeño en virtio_net_hdr_to_skb() syzbot pudo activar esta advertencia [1], después de inyectar un paquete malicioso a través de af_packet, configurando skb->csum_start y, por lo tanto, el encabezado de transporte con un valor incorrecto. Al menos podemos asegurarnos de que el encabezado de transporte esté después del final del encabezado de red (con un tamaño mínimo estimado). [1] [ 67.873027] longitud skb=4096 espacio libre=16 longitud libre=14 espacio libre=0 mac=(-1,-1) longitud_mac=0 red=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(tamaño=0 tipo=0 segmentos=0)) suma_c(0xa inicio=10 desplazamiento=0 suma_ip=3 software_completo=0 válido=0 nivel=0) hash(0x0 software=0 l4=0) proto=0x0800 tipo_paquete=0 iif=0 prioridad=0x0 marca=0x0 asignar_cpu=10 vlan_all=0x0 encapsulación=0 interno(proto=0x0000, mac=0, red=0, trans=0) [ 67.877172] nombre_de_desarrollo=veth0_vlan hazaña=0x000061164fdd09e9 [ 67.877764] familia sk=17 tipo=3 proto=0 [ 67.878279] skb lineal: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] fragmento skb: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] fragmento skb: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [67.882173] fragmento de skb: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [67.882790] fragmento de skb: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] fragmento: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] fragmento skb: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] fragmento skb: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] fragmento skb: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] fragmento de skb: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] fragmento de skb: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] fragmento de skb: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] fragmento skb: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] fragmento skb: 00000100: 00 00 [ 67.887878] ------------[ cortar aquí ]------------ [ 67.887908] desplazamiento (-6) >= skb_headlen() (14) [ 67.888445] ADVERTENCIA: CPU: 10 PID: 2088 en net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminador 2)) [ 67.889353] Módulos vinculados en: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 puente ficticio sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 No contaminado 6.11.0-virtme #1011 [ 67.890183] Nombre del hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminador 2)) [ 67.891043] Seguimiento de llamadas: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminador 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminador 1)) [ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se corrige el fallo causado por llamar a __xfrm_state_delete() dos veces. El km.state no se comprueba en el trabajo retrasado del controlador. Cuando se llama a xfrm_state_check_expire(), el estado se puede restablecer a XFRM_STATE_EXPIRED, incluso si ya está XFRM_STATE_DEAD. Esto sucede cuando se elimina el estado de xfrm, pero aún no se libera. Cuando se vuelve a llamar a __xfrm_state_delete() en el temporizador de xfrm, se produce el siguiente fallo. Para solucionar este problema, omita xfrm_state_check_expire() si km.state no es XFRM_STATE_VALID. Ups: fallo de protección general, probablemente para la dirección no canónica 0xdead000000000108: 0000 [#1] CPU SMP: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 No contaminado 6.11.0-rc2+ #1 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Cola de trabajo: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Código: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: muerto000000000122 RBX: ffffffff82afa940 RCX: 00000000000000036 RDX: muerto000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: se corrige el error doble destroy_workqueue Cuando falla gfs2_fill_super(), se llama destroy_workqueue() dentro de gfs2_gl_hash_clear() y la ruta de código posterior vuelve a llamar a destroy_workqueue() en la misma cola de trabajo. Este problema se puede solucionar configurando el puntero de la cola de trabajo en NULL después de la primera llamada destroy_workqueue() y comprobando si hay un puntero NULL antes de intentar destruir la cola de trabajo nuevamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: MGMT: Se corrige un posible fallo en mgmt_index_removed Si se llama a mgmt_index_removed mientras hay comandos en cola en cmd_sync, podría provocar fallos como el siguiente seguimiento: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] Entonces, mientras se maneja mgmt_index_removed, esto intenta quitar de la cola los comandos pasados como usuario_data a cmd_sync.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ppp: no asuma que bh se mantiene en ppp_channel_bridge_input() La ruta de recepción de red generalmente se maneja desde el controlador BH. Sin embargo, algunos protocolos necesitan adquirir el bloqueo del socket y los paquetes pueden almacenarse en el backlog del socket si el socket era propiedad de un proceso de usuario. En este caso, release_sock(), __release_sock() y sk_backlog_rcv() pueden llamar al controlador sk->sk_backlog_rcv() en el contexto del proceso. sybot capturó que ppp no estaba considerando este caso en ppp_channel_bridge_input(): ADVERTENCIA: estado de bloqueo inconsistente 6.11.0-rc7-syzkaller-g5f5673607153 #0 No contaminado -------------------------------- uso inconsistente de {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W}. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] toma: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: spin_lock include/linux/spinlock.h:351 [en línea] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [en línea] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, en: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 El estado {SOFTIRQ-ON-W} se registró en: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [en línea] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [en línea] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [en línea] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv incluir/net/sock.h:1111 [en línea] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [en línea] __se_sys_sendto net/socket.c:2212 [en línea] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 marca de evento de irq: 282914 hardirqs habilitados por última vez en (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [en línea] hardirqs habilitados por última vez en (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs deshabilitados por última vez en (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [en línea] hardirqs se desactivó por última vez en (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs se activó por última vez en (282904): [] softirq_handle_end kernel/softirq.c:400 [en línea] softirqs se activó por última vez en (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs se desactivó por última vez en (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** BLOQUEO INTERMEDIO *** 1 bloqueo mantenido por ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 seguimiento de pila: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 No contaminado 6.11.0-rc7-syzkaller-g5f5673607153 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Seguimiento de llamadas: dump_backtrace+0x1b8/0x1e4 arch/ar---truncado---