Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: wpcm-fiu: Corrige una potencial desreferencia de puntero NULL en wpcm_fiu_probe()<br /> <br /> platform_get_resource_byname() puede devolver NULL, lo que provocaría un fallo al pasarle el puntero a resource_size().<br /> <br /> Mover la asignación de fiu-&gt;memory_size después de la comprobación de errores para devm_ioremap_resource() para evitar la potencial desreferencia de puntero NULL.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv6: Corrección de acceso fuera de límites en fib6_add_rt2node().<br /> <br /> syzbot informó una lectura fuera de límites en fib6_add_rt2node(). [0]<br /> <br /> Cuando se crea una ruta IPv6 con RTA_NH_ID, struct fib6_info no tiene la struct fib6_nh final.<br /> <br /> El commit citado comenzó a verificar !iter-&gt;fib6_nh-&gt;fib_nh_gw_family para asegurar que rt6_qualify_for_ecmp() devuelva falso para iter.<br /> <br /> Si iter-&gt;nh no es NULL, rt6_qualify_for_ecmp() devuelve falso de todos modos.<br /> <br /> Verifiquemos iter-&gt;nh antes de leer iter-&gt;fib6_nh y evitemos la lectura OOB.<br /> <br /> [0]:<br /> ERROR: KASAN: slab-fuera-de-límites en fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142<br /> Lectura de tamaño 1 en la dirección ffff8880384ba6de por la tarea syz.0.18/5500<br /> <br /> CPU: 0 UID: 0 PID: 5500 Comm: syz.0.18 No contaminado syzkaller #0 PREEMPT(full)<br /> Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Rastro de llamada:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xba/0x230 mm/kasan/report.c:482<br /> kasan_report+0x117/0x150 mm/kasan/report.c:595<br /> fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142<br /> fib6_add_rt2node_nh net/ipv6/ip6_fib.c:1363 [inline]<br /> fib6_add+0x910/0x18c0 net/ipv6/ip6_fib.c:1531<br /> __ip6_ins_rt net/ipv6/route.c:1351 [inline]<br /> ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3957<br /> inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660<br /> rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592<br /> ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646<br /> __sys_sendmsg net/socket.c:2678 [inline]<br /> __do_sys_sendmsg net/socket.c:2683 [inline]<br /> __se_sys_sendmsg net/socket.c:2681 [inline]<br /> __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f9316b9aeb9<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffd8809b678 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f9316e15fa0 RCX: 00007f9316b9aeb9<br /> RDX: 0000000000000000 RSI: 0000200000004380 RDI: 0000000000000003<br /> RBP: 00007f9316c08c1f R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f9316e15fac R14: 00007f9316e15fa0 R15: 00007f9316e15fa0<br /> <br /> <br /> Asignado por la tarea 5499:<br /> kasan_save_stack mm/kasan/common.c:57 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __do_kmalloc_node mm/slub.c:5657 [inline]<br /> __kmalloc_noprof+0x40c/0x7e0 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> fib6_info_alloc+0x30/0xf0 net/ipv6/ip6_fib.c:155<br /> ip6_route_info_create+0x142/0x860 net/ipv6/route.c:3820<br /> ip6_route_add+0x49/0x1b0 net/ipv6/route.c:3949<br /> inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660<br /> rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592<br /> ___sys_s<br /> ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ASoC: fsl_xcvr: Revertir corrección de bloqueo faltante en fsl_xcvr_mode_put()<br /> <br /> Esto revierte el commit f51424872760 (&amp;#39;ASoC: fsl_xcvr: corregir bloqueo faltante en fsl_xcvr_mode_put()&amp;#39;).<br /> <br /> El parche original intentó adquirir el bloqueo card-&gt;controls_rwsem en fsl_xcvr_mode_put(). Sin embargo, esta función es llamada desde la función central superior de ALSA snd_ctl_elem_write(), que ya mantiene el bloqueo de escritura en controls_rwsem para toda la operación &amp;#39;put&amp;#39;. Así que no hay necesidad de simplemente mantener el bloqueo para fsl_xcvr_activate_ctl() de nuevo.<br /> <br /> Adquirir el bloqueo de lectura mientras se mantiene el bloqueo de escritura en el mismo hilo resulta en un interbloqueo y una tarea colgada, según lo informado por Alexander Stein.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amd/display: Corrección de índice de codificador de flujo fuera de límites v3<br /> <br /> eng_id puede ser negativo y que stream_enc_regs[]<br /> puede ser indexado fuera de límites.<br /> <br /> eng_id se usa directamente como un índice en stream_enc_regs[], que tiene<br /> solo 5 entradas. Cuando eng_id es 5 (ENGINE_ID_DIGF) o negativo, esto puede<br /> acceder a memoria más allá del final del array.<br /> <br /> Añadir una comprobación de límites usando ARRAY_SIZE() antes de usar eng_id como un índice.<br /> La conversión a tipo sin signo también rechaza valores negativos.<br /> <br /> Esto evita el acceso fuera de límites.<br /> <br /> Corrige el siguiente error de smatch:<br /> dcn_resource.c: stream_encoder_create() puede indexar<br /> stream_enc_regs[eng_id] fuera de límites (tamaño 5).<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351_resource.c<br /> 1246 static struct stream_encoder dcn35_stream_encoder_create(<br /> 1247 enum engine_id eng_id,<br /> 1248 struct dc_context ctx)<br /> 1249 {<br /> <br /> ...<br /> <br /> 1255<br /> 1256 /* Mapeo de bloques de registro VPG, AFMT, DME a instancia de bloque DIO */<br /> 1257 if (eng_id

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/xe/pf: Corrección de la inicialización de sysfs<br /> <br /> En caso de fallo de devm_add_action_or_reset(), la acción de limpieza proporcionada se ejecutará inmediatamente en el kobject aún no inicializado. Esto puede provocar errores como:<br /> <br /> [ ] kobject: &amp;#39;(null)&amp;#39; (ff110001393608e0): no está inicializado, sin embargo, se está llamando a kobject_put().<br /> [ ] ADVERTENCIA: lib/kobject.c:734 en kobject_put+0xd9/0x250, CPU#0: kworker/0:0/9<br /> [ ] RIP: 0010:kobject_put+0xdf/0x250<br /> [ ] Call Trace:<br /> [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe]<br /> [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe]<br /> [ ] xe_sriov_init_late+0x5f/0x2c0 [xe]<br /> [ ] xe_device_probe+0x5f2/0xc20 [xe]<br /> [ ] xe_pci_probe+0x396/0x610 [xe]<br /> [ ] local_pci_probe+0x47/0xb0<br /> <br /> [ ] refcount_t: desbordamiento negativo; uso después de liberación.<br /> [ ] ADVERTENCIA: lib/refcount.c:28 en refcount_warn_saturate+0x68/0xb0, CPU#0: kworker/0:0/9<br /> [ ] RIP: 0010:refcount_warn_saturate+0x68/0xb0<br /> [ ] Call Trace:<br /> [ ] kobject_put+0x174/0x250<br /> [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe]<br /> [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe]<br /> [ ] xe_sriov_init_late+0x5f/0x2c0 [xe]<br /> [ ] xe_device_probe+0x5f2/0xc20 [xe]<br /> [ ] xe_pci_probe+0x396/0x610 [xe]<br /> [ ] local_pci_probe+0x47/0xb0<br /> <br /> Esto se soluciona llamando a kobject_init() y kobject_add() por separado y registrando la acción de limpieza después de que el kobject esté inicializado.<br /> <br /> También se hace que este registro de limpieza sea parte del asistente de creación para corregir otro error, ya que en el bucle estábamos pasando incorrectamente el kobject padre al registrar la acción de limpieza, y esto resultó en algunas fugas no detectadas.<br /> <br /> (seleccionado de la confirmación 98b16727f07e26a5d4de84d88805ce7ffcfdd324)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> pstore/ram: corrige desbordamiento de búfer en persistent_ram_save_old()<br /> <br /> persistent_ram_save_old() puede ser llamada múltiples veces para la misma persistent_ram_zone (por ejemplo, a través de ramoops_pstore_read -&gt; ramoops_get_next_prz para registros PSTORE_TYPE_DMESG).<br /> <br /> Actualmente, la función solo asigna prz-&gt;old_log cuando es NULL, pero actualiza incondicionalmente prz-&gt;old_log_size al tamaño de búfer actual y luego realiza memcpy_fromio() usando este nuevo tamaño. Si el tamaño del búfer ha crecido desde la primera asignación (lo que puede ocurrir en diferentes ciclos de arranque del kernel), esto lleva a:<br /> <br /> 1. Un desbordamiento de búfer de pila (escritura OOB) en las llamadas a memcpy_fromio()<br /> 2. Una lectura OOB posterior cuando ramoops_pstore_read() accede al búfer usando el old_log_size incorrecto (más grande)<br /> <br /> El splat de KASAN se vería similar a:<br /> BUG: KASAN: slab-out-of-bounds en ramoops_pstore_read+0x...<br /> Lectura de tamaño N en la dirección ... por la tarea ...<br /> <br /> Es probable que las condiciones sean extremadamente difíciles de alcanzar:<br /> <br /> 0. Fallo con una escritura de ramoops de menos de record-max-size bytes.<br /> 1. Reinicio: ramoops se registra, pstore_get_records(0) lee el fallo antiguo, asigna old_log con tamaño X<br /> 2. Gestor de fallos registrado, temporizador iniciado (si pstore_update_ms &gt;= 0)<br /> 3. Ocurre un oops (no fatal, el sistema continúa)<br /> 4. pstore_dump() escribe el oops a través de ramoops_pstore_write() tamaño Y (&gt;X)<br /> 5. pstore_new_entry = 1, se llama a pstore_timer_kick()<br /> 6. El sistema continúa ejecutándose (no es un oops de pánico)<br /> 7. El temporizador se activa después de pstore_update_ms milisegundos<br /> 8. pstore_timefunc() ? schedule_work() ? pstore_dowork() ? pstore_get_records(1)<br /> 9. ramoops_get_next_prz() ? persistent_ram_save_old()<br /> 10. buffer_size() devuelve Y, pero old_log es de X bytes<br /> 11. Y &gt; X: memcpy_fromio() desborda la pila<br /> <br /> Requisitos:<br /> - existe un registro de fallo anterior que no llenó el tamaño del registro (casi imposible ya que el gestor de fallos escribe tanto como puede caber en el registro, limitado por el tamaño máximo del registro y el búfer kmsg casi siempre excede el tamaño máximo del registro)<br /> - pstore_update_ms &gt;= 0 (deshabilitado por defecto)<br /> - Oops no fatal (el sistema sobrevive)<br /> <br /> Libera y reasigna el búfer cuando el nuevo tamaño difiere del tamaño previamente asignado. Esto asegura que old_log siempre tenga espacio suficiente para los datos que se están copiando.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> AppArmor: Permitir que apparmor maneje tablas dfa no alineadas<br /> <br /> Las tablas dfa pueden originarse desde el kernel o el espacio de usuario y la alineación de 8 bytes no siempre está garantizada y como tal puede desencadenar accesos a memoria no alineados en varias arquitecturas. Resultando en lo siguiente<br /> <br /> [ 73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720<br /> [ 74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom<br /> sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common<br /> [ 74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE<br /> [ 74.536543] Call Trace:<br /> [ 74.568561] [] dump_stack+0x8/0x18<br /> [ 74.633757] [] __warn+0xd8/0x100<br /> [ 74.696664] [] warn_slowpath_fmt+0x34/0x74<br /> [ 74.771006] [] aa_dfa_unpack+0x6cc/0x720<br /> [ 74.843062] [] unpack_pdb+0xbc/0x7e0<br /> [ 74.910545] [] unpack_profile+0xbe0/0x1300<br /> [ 74.984888] [] aa_unpack+0xe0/0x6a0<br /> [ 75.051226] [] aa_replace_profiles+0x64/0x1160<br /> [ 75.130144] [] policy_update+0xf0/0x280<br /> [ 75.201057] [] profile_replace+0xa8/0x100<br /> [ 75.274258] [] vfs_write+0x90/0x420<br /> [ 75.340594] [] ksys_write+0x4c/0xe0<br /> [ 75.406932] [] sys_write+0x14/0x40<br /> [ 75.472126] [] linux_sparc_syscall+0x34/0x44<br /> [ 75.548802] ---[ end trace 0000000000000000 ]---<br /> [ 75.609503] dfa blob stream 0xfff0000008926b96 not aligned.<br /> [ 75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720<br /> <br /> Solucionarlo utilizando las funciones auxiliares get_unaligned_xx().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: fsl-edma: no deshabilitar explícitamente los relojes en .remove()<br /> <br /> Los relojes en fsl_edma_engine::muxclk se asignan y habilitan con<br /> devm_clk_get_enabled(), lo que automáticamente libera estos recursos,<br /> pero estos relojes también se deshabilitan manualmente en fsl_edma_remove(). Esto<br /> causa advertencias al eliminar el controlador para cada reloj:<br /> <br /> edma_module ya deshabilitado<br /> ADVERTENCIA: CPU: 0 PID: 418 at drivers/clk/clk.c:1200 clk_core_disable+0x198/0x1c8<br /> [...]<br /> Traza de llamada:<br /> clk_core_disable+0x198/0x1c8 (P)<br /> clk_disable+0x34/0x58<br /> fsl_edma_remove+0x74/0xe8 [fsl_edma]<br /> [...]<br /> ---[ fin de la traza 0000000000000000 ]---<br /> edma_module ya no preparado<br /> ADVERTENCIA: CPU: 0 PID: 418 at drivers/clk/clk.c:1059 clk_core_unprepare+0x1f8/0x220<br /> [...]<br /> Traza de llamada:<br /> clk_core_unprepare+0x1f8/0x220 (P)<br /> clk_unprepare+0x34/0x58<br /> fsl_edma_remove+0x7c/0xe8 [fsl_edma]<br /> [...]<br /> ---[ fin de la traza 0000000000000000 ]---<br /> <br /> Solucionar estas advertencias eliminando la llamada innecesaria a fsl_disable_clocks()<br /> en fsl_edma_remove().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> NFS/localio: prevenir la recursión de recuperación directa en NFS a través de nfs_writepages<br /> <br /> LOCALIO es una optimización de montaje de bucle invertido de NFS que evita usar la red para LECTURA, ESCRITURA y COMMIT si se determina que el cliente y el servidor NFS están en el mismo sistema. Pero debido a que LOCALIO sigue siendo fundamentalmente &amp;#39;solo montaje de bucle invertido de NFS&amp;#39;, es susceptible a un interbloqueo por recursión a través de la recuperación directa, por ejemplo: NFS LOCALIO hasta XFS y luego de vuelta a NFS a través de nfs_writepages.<br /> <br /> Solucionar el potencial de LOCALIO para el interbloqueo por recuperación directa asegurando que todas sus asignaciones de caché de página se realicen desde el contexto GFP_NOFS.<br /> <br /> Gracias a Ben Coddington por señalar el commit ad22c7a043c2 (&amp;#39;xfs: prevenir desbordamientos de pila por asignación de caché de página&amp;#39;).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> clocksource/drivers/timer-sp804: Corregir un Oops cuando se llama a read_current_timer en plataformas ARM32 donde el SP804 no está registrado como el sched_clock.<br /> <br /> En SP804, el temporizador de retardo comparte la misma instancia de clkevt con sched_clock. En algunas plataformas, cuando se llama a sp804_clocksource_and_sched_clock_init con use_sched_clock no establecido en 1, sched_clkevt no se inicializa correctamente. Sin embargo, sp804_register_delay_timer se invoca incondicionalmente, y read_current_timer() posteriormente llama a sp804_read en un sched_clkevt no inicializado, lo que lleva a un Oops del kernel al acceder a sched_clkevt-&gt;value.<br /> <br /> Declarar una instancia de clkevt dedicada exclusivamente para el temporizador de retardo, en lugar de compartir el mismo clkevt con sched_clock. Esto asegura que read_current_timer continúe funcionando correctamente independientemente de si SP804 es seleccionado como el sched_clock.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gpio: cdev: Evitar desreferencia de NULL en linehandle_create()<br /> <br /> En linehandle_create(), hay una declaración como esta:<br /> retain_and_null_ptr(lh);<br /> <br /> Poco después, hay una impresión de depuración que desreferencia &amp;#39;lh&amp;#39;, lo que provocará un fallo.<br /> <br /> Evitar el fallo usando handlereq.lines, que es el mismo valor.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> procfs: corrige la falta de protección RCU al leer real_parent en do_task_stat()<br /> <br /> Al leer /proc/[pid]/stat, do_task_stat() accede a task-&gt;real_parent sin la protección RCU adecuada, lo que lleva a:<br /> <br /> cpu 0 cpu 1<br /> ----- -----<br /> do_task_stat<br /> var = task-&gt;real_parent<br /> release_task<br /> call_rcu(delayed_put_task_struct)<br /> task_tgid_nr_ns(var)<br /> rcu_read_lock real_parent!<br /> task_pid_ptr real_parent.