Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda/cs_dsp_ctl: use private_free para la limpieza del control. Use la devolución de llamada de control private_free para liberar el bloque de datos asociado. Esto garantiza que la memoria no se pierda, sea cual sea la forma en que se destruya el control. La implementación original en realidad no eliminó los controles ALSA en hda_cs_dsp_control_remove(). Sólo liberó la estructura de seguimiento interna. Esto significaba que era posible quitar/descargar el controlador del amplificador dejando sus controles ALSA todavía presentes en la tarjeta de sonido. Obviamente, intentar acceder a ellos podría provocar errores de segmentación o al menos eliminar la referencia a punteros obsoletos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/a6xx: evite una desreferencia de nullptr cuando falla la configuración de speedbin. Llamar a a6xx_destroy() antes de adreno_gpu_init() conduce a una desreferencia de puntero nulo en: msm_gpu_cleanup() : platform_set_drvdata(gpu- >pdev, NULO); ya que gpu->pdev solo se asigna en: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() En lugar de depender de comprobaciones nulas manuales en la cadena de limpieza, desasigne explícitamente los datos LLC y libere a6xx_gpu en su lugar. Remiendo: https://patchwork.freedesktop.org/patch/588919/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: null_blk: corrige la dereferencia null-ptr al configurar 'power' y 'submit_queues'. Escribir 'power' y 'submit_queues' simultáneamente provocará un pánico en el kernel: Script de prueba: modprobe null_blk nr_devices= 0 mkdir -p /sys/kernel/config/nullb/nullb0 mientras sea verdadero; hacer eco 1 > enviar_queues; eco 4 > enviar_colas; hecho y mientras sea cierto; hacer eco 1 > potencia; eco 0 > potencia; hecho Resultado de la prueba: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000148 Ups: 0000 [#1] RIP SMP PREEMPLEADO: 0010:__lock_acquire+0x41d/0x28f0 Seguimiento de llamada: lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive _eliminación+ 0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] /0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150 Esto se debe a que del_gendisk() puede concurrente con blk_mq_update_nr_hw_queues(): nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // todavía está configurado mientras se elimina gendisk return 0 blk_mq_update_nr_hw_queues dev->nullb = NULL Fix este problema reutilizando el mutex global para proteger nullb_device_power_store() y nullb_update_nr_hw_queues() de configfs.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nfnetlink_queue: adquirir rcu_read_lock() en instancia_destroy_rcu() syzbot informó que se podía llamar a nf_reinject() sin rcu_read_lock() : ADVERTENCIA: uso sospechoso de RCU 6.9.0-rc7-syzkaller -02060-g5c1672705a1a #0 ¡No está contaminado net/netfilter/nfnetlink_queue.c:263 uso sospechoso de rcu_dereference_check()! otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 2 bloqueos mantenidos por syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_lock_acquire include/linux/rcupdate.h:329 [en línea] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_do_batch kernel/rcu/tree.c:2190 [en línea] #0 : ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.} -{2:2}, en: spin_lock_bh include/linux/spinlock.h:356 [en línea] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, en: nfqnl_flush net/ netfilter/nfnetlink_queue.c:405 [en línea] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, en: instancia_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 pila backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 No contaminado 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Llamada de Google 02/04/2024 Trace: __dump_stack lib/dump_stack.c: 88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c: 114 Lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c: 6712 nf_filt. C :323 [en línea] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [en línea] instancia_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 do_batch kernel/rcu /tree.c:2196 [en línea] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [en línea] invoke_softirq kernel/softirq .c:428 [en línea] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [en línea] r_interrupción+ 0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige el desplazamiento fuera de los límites en dctcp_update_alpha(). En dctcp_update_alpha(), utilizamos un parámetro de módulo dctcp_shift_g de la siguiente manera: alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... entregado_ce <<= (10 - dctcp_shift_g); Parece que syzkaller comenzó a modificar los parámetros del módulo y activó el desplazamiento fuera de los límites [0] estableciendo 100 en dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47) ; res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Limitemos el valor máximo de dctcp_shift_g mediante param_set_uint_minmax(). Con este parche: # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: error de escritura: argumento no válido [0]: UBSAN: desplazamiento fuera de los límites en net/ipv4/tcp_dctcp.c:143:12 el exponente de desplazamiento 100 es demasiado grande para el tipo 'u32' de 32 bits (también conocido como 'int sin signo' ) CPU: 0 PID: 8083 Comm: syz-executor345 No contaminado 6.9.0-05151-g1b294a1f3561 #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c :468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [en línea] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 v_state_process+0x57a/0x2290 neto/ ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [en línea] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+ 0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0x ad0 net/mptcp/protocolo .c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [en línea] sock_close+0xc0/0x240 net/ socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [en línea] do_exit+0x9c8/0x2540 kernel/exit .c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [en línea] __se_sys_exit_group kernel/exit.c:1036 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:10 36 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Código: no se puede acceder a los bytes del código de operación en 0x7f6c2b50058c . RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 06 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_rx_work syzbot informó el siguiente problema de acceso al valor uninit [1] nci_rx_work() analiza el paquete recibido de ndev->rx_q. Se debe validar el tamaño del encabezado, el tamaño del payload y el tamaño total del paquete antes de procesar el paquete. Si se detecta un paquete no válido, se debe descartar silenciosamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: cyapa: agrega bloqueo del núcleo de entrada faltante para suspender/reanudar funciones. Toma entrada->mutex durante las funciones de suspensión/reanudación como se hace en otros controladores de entrada. Esto corrige la siguiente advertencia durante el ciclo de suspensión/reanudación del sistema en Snow Chromebook basado en Samsung Exynos5250: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU : 1 PID: 1680 en drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Módulos vinculados en: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Contaminado: GW 6.6.0-rc5-next -20231009 #14109 Nombre de hardware: Samsung Exynos (árbol de dispositivos aplanados) Cola de trabajo: events_unbound async_run_entry_fn unwind_backtrace de show_stack+0x10/0x14 show_stack de dump_stack_lvl+0x58/0x70 dump_stack_lvl de __warn+0x1a8/0x1cc __warn de warn _slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt de input_device_enabled+ 0x68/0x6c input_device_enabled de cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode de cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize de cyapa_resume+0x48/0x98 cyapa_resume de dpm_run_callback+0x90/ 0x298 dpm_run_callback de dispositivo_resume+0xb4/0x258 dispositivo_resume de async_resume+0x20/0x64 async_resume de async_run_entry_fn+0x40 /0x15c async_run_entry_fn de Process_scheduled_works+0xbc/0x6a8 Process_scheduled_works de trabajador_thread+0x188/0x454 trabajador_thread de kthread+0x108/0x140 kthread de ret_from_fork+0x14/0x28 Pila de excepciones (0xf1625fb0 a 0xf1 625ff8) ... ---[ final de seguimiento 0000000000000000 ]-- - ... ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 1680 en drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Módulos vinculados en: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: GW 6.6.0-rc5-next-20231009 #14109 Nombre de hardware: Samsung Exynos (árbol de dispositivos aplanados) Cola de trabajo : events_unbound async_run_entry_fn unwind_backtrace de show_stack+0x10/0x14 show_stack de dump_stack_lvl+0x58/0x70 dump_stack_lvl de __warn+0x1a8/0x1cc __warn de warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt de input_ dispositivo_enabled+0x68/0x6c input_device_enabled de cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode de cyapa_reinitialize+0x10c /0x15c cyapa_reinitialize de cyapa_resume+0x48/0x98 cyapa_resume de dpm_run_callback+0x90/0x298 dpm_run_callback de device_resume+0xb4/0x258 device_resume de async_resume+0x20/0x64 async_resume de async_run_entry_fn+0x40/0x 15c async_run_entry_fn de Process_scheduled_works+0xbc/0x6a8 Process_scheduled_works de trabajador_thread+0x188/ 0x454 work_thread de kthread+0x108/0x140 kthread de ret_from_fork+0x14/0x28 Pila de excepciones (0xf1625fb0 a 0xf1625ff8)... ---[fin de seguimiento 0000000000000000]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi: libstub: solo se libera priv.runtime_map cuando se asigna priv.runtime_map solo se asigna cuando efi_novamap no está configurado. De lo contrario, es un valor no inicializado. En la ruta del error se libera incondicionalmente. Evite pasar un valor no inicializado a free_pool. Priv.runtime_map gratuito solo cuando se asignó. Este error fue descubierto y resuelto utilizando Coverity Static Analysis Security Testing (SAST) por Synopsys, Inc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: extiende la restricción de intervalo mínimo a todo el ciclo también. Es posible que syzbot eluda la restricción impuesta por el commit culpable en la etiqueta Fixes:, porque el taprio UAPI permite un tiempo de ciclo diferente (y potencialmente más corto) de la suma de los intervalos de entrada. Necesitamos una restricción más, que es que el tiempo del ciclo en sí debe ser mayor que N * ETH_ZLEN bits, donde N es el número de entradas de programación. Esta restricción debe aplicarse independientemente de si el tiempo del ciclo provino del usuario o fue un valor implícito calculado automáticamente, por lo que movemos la verificación "ciclo == 0" existente fuera de "if "(!new->cycle_time)". rama. De esta manera cubre tanto las condiciones como los escenarios. Agregue una autoprueba que ilustre el problema desencadenado por syzbot.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: genirq/cpuhotplug, x86/vector: evita la fuga de vectores durante la CPU fuera de línea. La ausencia de IRQD_MOVE_PCNTXT impide la efectividad inmediata de la reconfiguración de la afinidad de interrupción a través de procfs. En cambio, el cambio se difiere hasta la siguiente instancia de interrupción que se activa en la CPU original. La siguiente vez que se activa la interrupción en la CPU original, la nueva afinidad se aplica dentro de __irq_move_irq(). Se asigna un vector desde la nueva CPU, pero el vector antiguo en la CPU original permanece y no se recupera inmediatamente. En su lugar, se marca apicd->move_in_progress y el proceso de recuperación se retrasa hasta el siguiente desencadenante de la interrupción en la nueva CPU. Tras la activación posterior de la interrupción en la nueva CPU, irq_complete_move() agrega una tarea a la lista vector_cleanup de la CPU anterior si permanece en línea. Posteriormente, el temporizador de la CPU antigua itera sobre su lista vector_cleanup, recuperando vectores antiguos. Sin embargo, surge un escenario poco común si la CPU antigua sale antes de que la interrupción se active nuevamente en la nueva CPU. En ese caso, irq_force_complete_move() no se invoca en la CPU saliente para recuperar el antiguo apicd->prev_vector porque la interrupción no es actualmente afín a la CPU saliente, e irq_needs_fixup() devuelve false. Aunque más tarde se llama a __vector_schedule_cleanup() en la nueva CPU, no reclama apicd->prev_vector; en su lugar, simplemente restablece apicd->move_in_progress y apicd->prev_vector a 0. Como resultado, el vector permanece sin reclamar en vector_matrix, lo que provoca una fuga de vector de CPU. Para solucionar este problema, mueva la invocación de irq_force_complete_move() antes de la llamada irq_needs_fixup() para recuperar apicd->prev_vector, si la interrupción es actualmente o solía ser afín a la CPU saliente. Además, recupere también el vector en __vector_schedule_cleanup(), después de un mensaje de advertencia, aunque en teoría nunca debería ver apicd->move_in_progress con apicd->prev_cpu apuntando a una CPU fuera de línea.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipvlan: no use skb->sk en ipvlan_process_v{4,6}_outbound El paquete sin procesar del socket PF_PACKET en la parte superior de un dispositivo ipvlan respaldado por IPv6 alcanzará WARN_ON_ONCE() en sk_mc_loop() a través de la ruta sch_direct_xmit(). ADVERTENCIA: CPU: 2 PID: 0 en net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Módulos vinculados en: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: cargado No contaminado 6.9.0+ #279 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Código: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 00000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? __advertir (kernel/panic.c:693)? sk_mc_loop (net/core/sock.c:760)? report_bug (lib/bug.c:201 lib/bug.c:219)? handle_bug (arch/x86/kernel/traps.c:239)? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminador 1))? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminador 1))? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222)? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev . c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043) La advertencia se activa de la siguiente manera: paquete_sendmsg paquete_snd //skb->sk es el paquete sk __dev_queue_xmit __dev_xmit_skb //q-> la cola no es NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //modo l3 ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //paquete de multidifusión sk_mc_loop //sk-> sk_family es AF_PACKET Llame a ip{6}_local_out() con NULL sk en ipvlan como otro túneles para solucionar este problema.

El producto IBM i 7.3, 7.4 y 7.5 IBM TCP/IP Connectivity Utilities para i contiene una vulnerabilidad de escalada de privilegios local. Un actor malintencionado con acceso a la línea de comandos del sistema operativo host puede elevar los privilegios para obtener acceso raíz al sistema operativo host. ID de IBM X-Force: 288171.