Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rcu/nocb: corrija WARN_ON_ONCE() en rcu_nocb_bypass_lock() Para los kernels creados con CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y y CONFIG_RCU_LAZY=y, los siguientes escenarios activarán WARN_ON_ONCE() en rcu_nocb_bypass_lock( ) y funciones rcu_nocb_wait_contended(): CPU2 CPU11 kthread rcu_nocb_cb_kthread ksys_write rcu_do_batch vfs_write rcu_torture_timer_cb proc_sys_write __kmem_cache_free proc_sys_call_handler kmemleak_free drop_caches_sysctl_handler delete_object_full losa __delete_object encogimiento_slab put_object lazy_rcu_shrink_scan call_rcu rcu_nocb_flush_bypass __call_rcu_commn rcu_nocb_bypass_lock raw_spin_trylock(&rdp->nocb_bypass_lock) fail atomic_inc(&rdp->nocb_lock_contended); rcu_nocb_wait_contended WARN_ON_ONCE(smp_processor_id()!= rdp->cpu); WARN_ON_ONCE(atomic_read(&rdp->nocb_lock_contended)) | |_ _ _ _ _ _ _ _ _ _mismo rdp y rdp->cpu != 11_ _ _ _ _ _ _ _ _ __| Reproduzca este error con "echo 3 > /proc/sys/vm/drop_caches". Por lo tanto, esta confirmación utiliza rcu_nocb_try_flush_bypass() en lugar de rcu_nocb_flush_bypass() en lazy_rcu_shrink_scan(). Si se está vaciando la cola nocb_bypass, entonces rcu_nocb_try_flush_bypass regresará directamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sysv: no llame a sb_bread() con pointers_lock retenido syzbot informa suspensión en contexto atómico en el sistema de archivos SysV [1], porque sb_bread() se llama con rw_spinlock retenido. Un error "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" y un error "sb_bread() with write_lock(&pointers_lock)" fueron introducidos por "Reemplazar BKL para bloqueo de cadena con sysvfs-private rwlock" en Linux 2.5.12. Luego, "[PATCH] err1-40: corrección de bloqueo de sysvfs" en Linux 2.6.8 solucionó el error anterior moviendo el bloqueo pointers_lock a las personas que llaman, pero en su lugar introdujo un error "sb_bread() con read_lock(&pointers_lock)" (que hizo que esto problema más fácil de abordar). Al Viro sugirió que por qué no hacer lo que hace get_branch()/get_block()/find_shared() en el sistema de archivos Minix. Y hacer eso es casi una reversión de "[PATCH] err1-40: corrección de bloqueo de sysvfs", excepto que get_branch() de find_shared() se llama sin write_lock(&pointers_lock).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf: corrige la desreferencia del puntero NULL en sanitycheck(). Si debido a un error en la asignación de memoria, mock_chain() devuelve NULL, se pasa a dma_fence_enable_sw_signaling(), lo que genera una desreferencia del puntero NULL allí. . Llame a dma_fence_enable_sw_signaling() solo si mock_chain() tiene éxito. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/bpf: Corrección de la aritmética del puntero bpf_plt Kui-Feng Lee informó un bloqueo en s390x provocado por la prueba dummy_st_ops/dummy_init_ptr_arg [1]: [<00000000000000002>] 0x2 [<00000000009d5cde> ] bpf_struct_ops_test_run+0x156/0x250 [<000000000033145a>] __sys_bpf+0xa1a/0xd00 [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50 [<0000000000 c4382c>] __do_syscall+0x244/0x300 [<0000000000c59a40>] system_call+0x70/0x98 Esto es causado por GCC mueve memcpy() después de las asignaciones en bpf_jit_plt(), lo que da como resultado que se escriban punteros NULL en lugar de las direcciones de retorno y de destino. Al observar los aspectos internos de GCC, se permite el reordenamiento porque el análisis de alias piensa que el destino memcpy() y los lados izquierdos de las asignaciones se basan en objetos diferentes: new_plt y bpf_plt_ret/bpf_plt_target respectivamente y, por lo tanto, no pueden crear alias. Esto, a su vez, se debe a una violación del estándar C: cuando se restan dos punteros, ambos apuntarán a elementos del mismo objeto de matriz, o uno más allá del último elemento del objeto de matriz... Desde la perspectiva de C, bpf_plt_ret y bpf_plt son objetos distintos y no se pueden restar. En términos prácticos, hacerlo confunde el análisis de alias del CCG. El código se escribió de esta manera para que el lado C conozca algunas compensaciones definidas en el ensamblaje. Si bien es agradable, esto no es necesario. Corrija el incumplimiento codificando estas compensaciones. [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/rds: corrige la posible desreferencia nula de cp cp podría ser nulo, llamar a cp->cp_conn produciría una desreferencia nula [Simon Horman agrega:] Análisis: * cp es un parámetro de __rds_rdma_map y no es reasignado. * Los siguientes sitios de llamadas pasan un argumento cp NULL a __rds_rdma_map() - rds_get_mr() - rds_get_mr_for_dest * Antes del código anterior, lo siguiente supone que cp puede ser NULL (lo cual es indicativo, pero podría ser innecesario) trans_private = rs ->rs_transport->get_mr( sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, args->vec.addr, args->vec.bytes, need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED); * El código modificado por este parche está custodiado por IS_ERR(trans_private), donde trans_private se asigna según el punto anterior de este análisis. La única implementación de get_mr que pude localizar es rds_ib_get_mr() que puede devolver un ERR_PTR si el argumento conn (cuarto) es NULL. * ret está establecido en PTR_ERR(trans_private). rds_ib_get_mr puede devolver ERR_PTR(-ENODEV) si el argumento de conexión (cuarto) es NULL. Por lo tanto, ret puede ser -ENODEV, en cuyo caso se ejecutará el código en cuestión. Conclusión: * cp puede ser NULL en el punto donde este parche agrega una verificación; este parche parece solucionar un posible error

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/bpf: corrige la IP después de emitir la contabilidad de profundidad de llamadas. Ajuste la IP pasada a `emit_patch` para que calcule el desplazamiento correcto para la instrucción CALL si `x86_call_ Depth_emit_accounting` emite código. De lo contrario, nos saltaremos algunas instrucciones y lo más probable es que fallemos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux: evita la desreferenciación de basura después de un error de montaje En caso de que kern_mount() falle y devuelva un puntero de error en la rama de error en lugar de continuar y desreferenciar el puntero de error. Mientras está en él, suelte la variable estática nunca leída selinuxfs_mount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Protección contra desbordamiento int para el tamaño de acceso a la pila. Este parche reintroduce la protección contra que el tamaño de acceso a la memoria de la pila sea negativo; el tamaño de acceso puede parecer negativo como resultado de desbordar su representación int firmada. En realidad, esto no debería suceder, ya que existen otras protecciones en el camino, pero debemos protegernos contra ello de todos modos. A una ruta de código le faltaban dichas protecciones (corregidas en el parche anterior de la serie), lo que provocaba accesos a matrices fuera de los límites en check_stack_range_initialized(). Este parche hace que falle la verificación de un programa con un tamaño de acceso tan absurdo. Esta verificación solía existir de una manera más indirecta, pero se eliminó inadvertidamente en a833a17aeac7.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: envía un mensaje de desactivación de DDTBCLK en la primera confirmación [Por qué] El parche anterior para permitir la desactivación de DDTBCLK no solucionaba el caso de inicio. El controlador cree que DTBCLK está deshabilitado de forma predeterminada, por lo que no enviamos mensajes de deshabilitación a PMFW. Luego, DTBCLK se habilita en el escritorio inactivo durante el arranque, consumiendo energía. [Cómo] Establezca dtbclk_en en verdadero en el arranque para que se envíe el mensaje de desactivación durante la primera confirmación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxbf_gige: llame a request_irq() después de inicializar NAPI. El controlador mlxbf_gige encuentra una excepción de puntero NULL en mlxbf_gige_open() cuando kdump está habilitado. La secuencia para reproducir la excepción es la siguiente: a) habilitar kdump b) activar kdump mediante "echo c > /proc/sysrq-trigger" c) el kernel de kdump se ejecuta d) el kernel de kdump carga el módulo mlxbf_gige e) el módulo mlxbf_gige se ejecuta en abierto () cuando se abre la interfaz "oob_net0" f) El módulo mlxbf_gige experimentará una excepción durante su apertura(), algo así como: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 Información de cancelación de memoria: ESR = 0x0000000086000004 EC = 0x21 : IABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: tabla de usuario de error de traducción de nivel 0: 4k páginas, VA de 48 bits, pgdp=00000000e29a4000 [00000000000000000] pgd=0000000000000000, p4d=00000000000000000 Error interno: Vaya: 0000000086000004 [#1] CPU SMP: 0 PID: 812 Comunicaciones: NetworkManager contaminado: G OE 5.15.0-1035-bluefield #37-Ubuntu Nombre de hardware: https ://www .mellanox.com Tarjeta principal BlueField-3 SmartNIC/Tarjeta principal BlueField-3 SmartNIC, BIOS 4.6.0.13024 19 de enero de 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: 7cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 00000000000000000 x20: 0000000000000001 x19: ffff000066027238 x 18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9: ffffa870b0842398 x8: 0000000000000004 x7: fe5a48b9069706ea x6: 17fdb11fc84ae0d2 x5: d94a82549d594f35 x4: 00000000000000 000 x3: 0000000000400100 x2: 0000000000000000 x1: 0000000000000000 x0: ffff000066027238 Llamar seguimiento: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x2 0/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+ 0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 bf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink +0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg +0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x54/0x184 do_el0_svc+0x30/0xac c+0x48/0x160 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Código: valor incorrecto de la PC ---[ seguimiento final 7d1c3f3bf9d81885 ]--- Pánico del kernel - no se sincroniza: Vaya: excepción grave en la interrupción Compensación del kernel: 0x2870a7a00000 de 0xffff800008000000 PHYS_OFFSET: 0x80000000 Características de la CPU: 0x0,000005c1,a33 32a5a Límite de memoria: ninguno --- [fin del pánico del kernel - no se sincroniza: Ups: excepción fatal en la interrupción]--- La excepción ocurre porque hay una interrupción RX pendiente antes de que se ejecute la llamada a request_irq(RX IRQ). Luego, el controlador RX IRQ se activa inmediatamente después de que se completa request_irq(). El ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tls: obtenga referencia de psock después de tomar rxlock para evitar fugas. Al inicio de tls_sw_recvmsg, tomamos una referencia en psock y luego llamamos a tls_rx_reader_lock. Si eso falla, volvemos directamente sin liberar la referencia. En lugar de agregar una nueva etiqueta, simplemente tome la referencia después de que el bloqueo se haya realizado correctamente, ya que no la necesitamos antes.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: wwan: t7xx: Accesos divididos de 64 bits para solucionar problemas de alineación Algunos de los registros están alineados en un límite de 32 bits, provocando fallos de alineación en plataformas de 64 bits. No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffffc084a1d004 Información de cancelación de memoria: ESR = 0x0000000096000061 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alineación falla Información de cancelación de datos: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 tabla de intercambio: 4k páginas, VA de 39 bits, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Error interno: Vaya: 0000000096000061 [#1] Módulos SMP vinculados en: mtk_t7xx(+) qcserial pppoe ppp_async opción nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 n ft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm c_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys CPU confiable: 3 PID: 5266 Comm: kworker/u9:1 ted: GO 6.6.22 #0 Nombre del hardware: Bananapi BPI -R4 (DT) Cola de trabajo: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr: _cldma_start+0xac/0x13c [mtk_t7xx] sp: ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 00000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c 0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 00000000000000001 x19: ffffff80c814b080 x18: 00000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 00000000000000000 x10: 0000000000000000 x9: 000 0000000000000 x8: ffffff80ca1ef6b4 x7: ffffff80c814b818 x6: 0000000000000018 x5: 0000000000000870 x4: 0000000000000000 x3: 0000000000000000 0 x2: 000000010a947000 x1: ffffffc084a1d004 x0: ffffffc084a1d004 Rastreo de llamadas: t7xx_cldma_hw_set_start_addr +0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] Process_one_work+0x154/0x2a0 Workers_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Código: f9400800 9 1001000 8b214001 d50332bf (f9000022) ---[ final de seguimiento 0000000000000000 ]--- La inclusión de io-64-nonatomic-lo-hi.h indica que todos los accesos de 64 bits pueden ser reemplazados por pares de accesos no atómicos de 32 bits. Corrija la alineación obligando a que todos los accesos sean de 32 bits en plataformas de 64 bits.