Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: systemport: corrige una posible pérdida de memoria en bcm_sysport_xmit(). Bcm_sysport_xmit() devuelve NETDEV_TX_OK sin liberar skb en caso de que dma_map_single() falle. Agregue dev_kfree_skb() para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/bnxt_re: Evitar bloqueos de CPU debido al bucle de comprobación de ocupación fifo El controlador espera indefinidamente a que la ocupación fifo baje de un umbral tan pronto como se recibe la interrupción de ritmo. Esto puede provocar un bloqueo suave en uno de los procesadores, si la tasa de DB es muy alta. Agregue un recuento de bucles para FPGA y salga de __wait_for_fifo_occupancy_below_th si el bucle está tomando más tiempo. El ritmo continuará hasta que la ocupación esté por debajo del umbral. Esto se garantiza mediante las comprobaciones en bnxt_re_pacing_timer_exp y la programación adicional del trabajo para el ritmo en función de la ocupación fifo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/bnxt_re: Se ha corregido la comprobación fuera de los límites. El controlador exporta estadísticas de ritmo solo en adaptadores GenP5 y P7. Pero al analizar las estadísticas de ritmo, el controlador tiene una comprobación para "rdev->dbr_pacing". Esto provocó un seguimiento cuando KASAN está habilitado. ERROR: KASAN: slab-out-of-bounds en bnxt_re_get_hw_stats+0x2b6a/0x2e00 [bnxt_re] Escritura de tamaño 8 en la dirección ffff8885942a6340 por la tarea modprobe/4809

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: Se corrige la doble liberación en scmi_debugfs_common_setup() El verificador estático de Clang (scan-build) arroja la siguiente advertencia: | drivers/firmware/arm_scmi/driver.c:line 2915, column 2 | Intenta liberar la memoria liberada. Cuando devm_add_action_or_reset() falla, scmi_debugfs_common_cleanup() se ejecutará dos veces, lo que provoca una doble liberación de 'dbg->name'. Elimina el scmi_debugfs_common_cleanup() redundante para solucionar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Verificar el info_cnt restante antes de repetir los campos btf Al intentar repetir los campos btf para una matriz de estructuras anidadas, no verifica el info_cnt restante. Se informará el siguiente error cuando el valor de ret * nelems sea mayor que BTF_FIELDS_MAX: ------------[ cortar aquí ]------------ UBSAN: array-index-out-of-bounds en ../kernel/bpf/btf.c:3951:49 el índice 11 está fuera de rango para el tipo 'btf_field_info [11]' CPU: 6 UID: 0 PID: 411 Comm: test_progs ...... 6.11.0-rc4+ #1 Tainted: [O]=OOT_MODULE Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ... Seguimiento de llamadas: dump_stack_lvl+0x57/0x70 dump_stack+0x10/0x20 ubsan_epilogue+0x9/0x40 __ubsan_handle_fuera_de_límites+0x6f/0x80 ? kallsyms_lookup_name+0x48/0xb0 btf_parse_fields+0x992/0xce0 map_create+0x591/0x770 __sys_bpf+0x229/0x2410 __x64_sys_bpf+0x1f/0x30 x64_sys_call+0x199/0x9f0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fea56f2cc5d ...... ---[ fin del seguimiento ]--- Arréglelo comprobando el info_cnt restante en btf_repeat_fields() antes de repetir los campos btf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: preservar param->string al analizar las opciones de montaje. En bpf_parse_param(), mantenga intacto el valor de param->string para que pueda liberarse más tarde. De lo contrario, el área kmalloc a la que apunta param->string se filtrará como se muestra a continuación: objeto sin referencia 0xffff888118c46d20 (tamaño 8): comm "new_name", pid 12109, jiffies 4295580214 volcado hexadecimal (primeros 8 bytes): 61 6e 79 00 38 c9 5c 7e any.8.\~ backtrace (crc e1b7f876): [<00000000c6848ac7>] kmemleak_alloc+0x4b/0x80 [<00000000de9f7d00>] __kmalloc_node_track_caller_noprof+0x36e/0x4a0 [<000000003e29b886>] memdup_user+0x32/0xa0 [<0000000007248326>] strndup_user+0x46/0x60 [<0000000035b3dd29>] __x64_sys_fsconfig+0x368/0x3d0 [<0000000018657927>] x64_sys_call+0xff/0x9f0 [<00000000c0cabc95>] do_syscall_64+0x3b/0xc0 [<000000002f331597>] entrada_SYSCALL_64_after_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fsl/fman: se ha corregido el manejo de refcount de dispositivos relacionados con fman En mac_probe() hay múltiples llamadas a of_find_device_by_node(), fman_bind() y fman_port_bind() que toman referencias a of_dev->dev. No todas las referencias tomadas por estas llamadas se liberan más tarde en la ruta de error en mac_probe() y en mac_remove(), lo que provoca fugas de referencias. Agregar referencias release.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige la sobrecarga del significado de MEM_UNINIT Lonial informó de un problema en el verificador BPF donde check_mem_size_reg() tiene el siguiente código: if (!tnum_is_const(reg->var_off)) /* Para accesos a variables sin privilegios, deshabilitar el modo sin formato * para que el programa deba * inicializar toda la memoria que el ayudante podría * llenar parcialmente. */ meta = NULL; Esto significa que las escrituras no se verifican cuando el registro que contiene el tamaño del búfer pasado no tiene un tamaño fijo. A través de este error, un programa BPF puede escribir en un mapa que está marcado como de solo lectura, por ejemplo, mapas globales .rodata. El problema es que el significado inicial de MEM_UNINIT de que "el buffer pasado al ayudante BPF no necesita ser inicializado" que se agregó en el commit 435faee1aae9 ("bpf, verificador: agregar tipo ARG_PTR_TO_RAW_STACK") se sobrecargó con el tiempo con "se está escribiendo en el búfer pasado". Sin embargo, el problema es que las comprobaciones como la anterior que se agregaron más tarde a través de 06c1c049721a ("bpf: permitir que los ayudantes accedan a la memoria variable") establecen meta en NULL para obligar al usuario a inicializar siempre el búfer pasado al ayudante. Debido al doble significado actual de MEM_UNINIT, esto omite las comprobaciones de escritura del verificador en la memoria (aunque no las comprobaciones de los límites) y solo supone que se lee la última memoria en su lugar. Solucione esto revirtiendo MEM_UNINIT a su significado original y haciendo que MEM_WRITE sea una anotación para los ayudantes de BPF para luego activar las comprobaciones del verificador de BPF para escribir en la memoria. Algunas notas: check_arg_pair_ok() garantiza que para ARG_CONST_SIZE{,_OR_ZERO} podamos acceder a fn->arg_type[arg - 1] ya que debe contener un ARG_PTR_TO_MEM anterior. Para check_mem_reg(), el argumento meta se puede eliminar por completo ya que verificamos tanto BPF_READ como BPF_WRITE. Lo mismo para el check_kfunc_mem_size_reg() equivalente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: use cond_resched() en nsim_dev_trap_report_work() Todavía veo muchos informes de syzbot que insinúan que syzbot podría engañar a nsim_dev_trap_report_work() con cientos de puertos [1] Usemos cond_resched() y system_unbound_wq en lugar de system_wq implícito. [1] INFORMACIÓN: tarea syz-executor:20633 bloqueada durante más de 143 segundos. No contaminada 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. tarea:syz-executor estado:D pila:25856 pid:20633 tgid:20633 ppid:1 indicadores:0x00004006 ... Seguimiento NMI para CPU 1 CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 No contaminado 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: eventos nsim_dev_trap_report_work RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210 Código: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0 RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246 RAX: 00000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00 RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577 R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000 R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 spin_unlock_bh include/linux/spinlock.h:396 [en línea] nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [en línea] nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850 process_one_work kernel/workqueue.c:3229 [en línea] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 subproceso de trabajo+0x870/0xd30 kernel/workqueue.c:3391 subproceso de trabajo+0x2f0/0x390 kernel/kthread.c:389 ret_de_la_bifurcación+0x4b/0x80 arch/x86/kernel/process.c:147 ret_de_la_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm: Evitar la desreferenciación NULL en msm_disp_state_print_regs() Si la asignación en msm_disp_state_dump_regs() falla, entonces `block->state` puede ser NULL. La función msm_disp_state_print_regs() _sí_ tiene código para intentar manejarlo con: if (*reg) dump_addr = *reg; ...pero como "dump_addr" se inicializa a NULL, lo anterior es en realidad un noop. Luego, el código continúa para desreferenciar `dump_addr`. Haga que la función imprima "Registros no almacenados" cuando vea un NULL para resolver esto. Ya que estamos tocando el código, arregle msm_disp_state_print_regs() para que no tome un puntero doble sin sentido y marque correctamente el puntero como `const`. Parche: https://patchwork.freedesktop.org/patch/619657/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda/cs8409: Se corrige una posible desreferencia de NULL. Si snd_hda_gen_add_kctl no puede asignar memoria y devuelve NULL, se producirá una desreferencia de puntero NULL en la siguiente línea. Dado que la función dolphin_fixups es una función hda_fixup que no debería devolver ningún error, se debe agregar una comprobación simple antes de la desreferencia e ignorar el error. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: devmap: proporcionar rxq después de la redirección rxq contiene un puntero al dispositivo desde donde se produjo la redirección. Actualmente, el programa BPF que se ejecutó después de una redirección a través de BPF_MAP_TYPE_DEVMAP* no lo tiene configurado. Esto es particularmente malo ya que se accede a ingress_ifindex, p. ej. SEC("xdp") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC("xdp/devmap") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS; } depende del acceso a rxq, por lo que un puntero NULL se desreferencia: <1>[ 574.475170] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 <1>[ 574.475188] #PF: acceso de lectura del supervisor en modo núcleo <1>[ 574.475194] #PF: error_code(0x0000) - página no presente <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 No contaminado 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Nombre del hardware: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 14/03/2023 <4>[ 574.475231] Cola de trabajo: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Código: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 00000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Rastreo de llamadas: <4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] proceso_uno_trabajo+0x15d/0x380 <4>[ 574.475566] subproceso_trabajador+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncado---