Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: Arreglar la longitud máxima del nombre de celda El sistema de archivos kafs limita la longitud máxima de una celda a 256 bytes, pero ocurre un problema si alguien realmente hace eso: kafs intenta crear un directorio bajo /proc/net/afs/ con el nombre de la celda, pero eso falla con una advertencia: ADVERTENCIA: CPU: 0 PID: 9 en fs/proc/generic.c:405 porque procfs limita la longitud máxima del nombre de archivo a 255. Sin embargo, el DNS limita la longitud máxima de búsqueda y, por extensión, el nombre máximo de celda, a 255 menos dos (recuento de longitud y NUL final). Arregle esto limitando la longitud máxima aceptable del nombre de celda a 253. Esto también nos permite estar seguros de que podemos crear el punto de montaje "/afs/./" también. Además, divida el nombre de celda del registro YFS VL al máximo de 256 permitido por el protocolo e ignore el registro recuperado por YFSVL.GetCellName si excede 253.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched: sch_cake: agregar comprobaciones de los límites a los recuentos de equidad de flujo masivo del host Aunque arreglamos un error lógico en el commit citada a continuación, syzbot aún logró activar un desbordamiento de los contadores de flujo masivo por host, lo que provocó un acceso a la memoria fuera de los límites. Para evitar que dichos errores lógicos provoquen accesos a la memoria fuera de los límites, esta confirmación elimina todos los accesos a los contadores de flujo masivo por host a una serie de ayudantes que realizan la comprobación de los límites antes de cualquier incremento o decremento. Esto también tiene el beneficio de mejorar la legibilidad al mover las comprobaciones condicionales para el modo de flujo a estos ayudantes, en lugar de tenerlas distribuidas por todo el código (que era la causa del error lógico original). Como parte de este cambio, el cálculo cuántico de flujo se consolida en una función auxiliar, lo que significa que el tramado aplicado al escalamiento de carga ost ahora se aplica tanto en la rotación DRR como cuando se inicia por primera vez el cuántico de un flujo disperso. El único efecto visible para el usuario es que el tamaño máximo de paquete que se puede enviar mientras un flujo permanece disperso variará ahora en +/- un byte en algunos casos. Esto no debería suponer una diferencia notable en la práctica y, por lo tanto, no vale la pena complicar el código para conservar el comportamiento anterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: conntrack: fijar el tamaño máximo de la tabla hash a INT_MAX Utilice INT_MAX como tamaño máximo para la tabla hash de conntrack. De lo contrario, es posible alcanzar WARN_ON_ONCE en __kvmalloc_node_noprof() al cambiar el tamaño de la tabla hash porque __GFP_NOWARN no está configurado. Consulte: 0708a0afe291 ("mm: Considere el indicador __GFP_NOWARN para llamadas kvmalloc() de gran tamaño") Nota: el cambio de tamaño de la tabla hash solo es posible desde init_netns.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: cls_flow: validar el atributo TCA_FLOW_RSHIFT syzbot encontró que el atributo TCA_FLOW_RSHIFT no estaba validado. El uso de un entero de 32 bits con valores de desplazamiento grandes no está definido. UBSAN: cambio fuera de los límites en net/sched/cls_flow.c:329:23 El exponente de cambio 9445 es demasiado grande para el tipo de 32 bits 'u32' (también conocido como 'unsigned int') CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 No contaminado 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: ipv6_addrconf addrconf_dad_work Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329 tc_classify include/net/tc_wrapper.h:197 [en línea] __tcf_classify net/sched/cls_api.c:1771 [en línea] tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867 sfb_classify net/sched/sch_sfb.c:260 [en línea] sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318 dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793 __dev_xmit_skb net/core/dev.c:3889 [en línea] __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [en línea] neigh_hh_output include/net/neighbour.h:523 [en línea] neigh_output include/net/neighbour.h:537 [en línea] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173 geneve_xmit_skb drivers/net/geneve.c:916 [en línea] geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 __netdev_start_xmit include/linux/netdevice.h:5002 [en línea] netdev_start_xmit include/linux/netdevice.h:5011 [en línea] xmit_one net/core/dev.c:3590 [en línea] dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606 __dev_queue_xmit+0x1b73/0x3f50 red/núcleo/dev.c:4434

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86/amd/pmc: Solo deshabilitar la activación de IRQ1 donde i8042 realmente la habilitó La activación para IRQ1 debe deshabilitarse solo en los casos en que i8042 realmente la haya habilitado, de lo contrario, "wake_depth" para esta IRQ intentará caer por debajo de cero y se registrará un WARN() desagradable: kernel: atkbd serio0: Deshabilitar la fuente de activación de IRQ1 para evitar un error de firmware de la plataforma kernel: ------------[ cortar aquí ]------------ kernel: Deshabilitar activación de IRQ 1 no balanceada kernel: ADVERTENCIA: CPU: 10 PID: 6431 en kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0 El controlador PMC usa DEFINE_SIMPLE_DEV_PM_OPS() para definir su dev_pm_ops que establece amd_pmc_suspend_handler() en .suspend, .freeze y .poweroff. Sin embargo, i8042_pm_suspend() solo se configura como el controlador .suspend. Solucione el problema llamando al controlador de suspensión PMC solo desde el mismo conjunto de controladores dev_pm_ops que i8042_pm_suspend(), lo que actualmente significa solo el controlador .suspend. Para reproducir este problema, intente hibernar (S4) la máquina después de un arranque nuevo sin ponerla primero en s2idle. [ij: edité el mensaje de confirmación].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rds: sysctl: rds_tcp_{rcv,snd}buf: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), p. ej. cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura per-netns se puede obtener de table->data usando Container_of(), luego la 'net' se puede recuperar del socket de escucha (si está disponible).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: sysctl: blackhole timeout: avoid using current->nsproxy Como se mencionó en el commit anterior, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de las redes de red del lector/escritor frente a solo de las redes de red del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), por ejemplo, cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'pernet' se puede obtener de table->data usando Container_of().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: sysctl: sched: evitar usar current->nsproxy No se recomienda usar la estructura 'net' a través de 'current' por diferentes razones. Primero, si el objetivo es usarlo para leer o escribir datos per-netns, esto es inconsistente con cómo funcionan las entradas sysctl "genéricas": directamente usando solo punteros configurados en la entrada de la tabla, por ejemplo table->data. Vinculado a eso, los datos per-netns siempre deben obtenerse de la tabla vinculada a los netns para los que se crearon, que pueden no coincidir con los netns del lector o escritor. Otra razón es que el acceso a current->nsproxy->netns puede fallar si se intenta cuando current->nsproxy se ha eliminado cuando la tarea actual está saliendo. Esto es lo que syzbot encontró al usar acct(2): Oops: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 5924 Comm: syz-executor No contaminado 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Código: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00 RSP: 0018:ffffc900034774e8 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620 RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028 RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040 R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000 R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000 FS: 000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601 __kernel_write_iter+0x318/0xa80 fs/read_write.c:612 __kernel_write+0xf6/0x140 fs/read_write.c:632 do_acct_process+0xcb0/0x14a0 kernel/acct.c:539 acct_pin_kill+0x2d/0x100 kernel/acct.c:192 pin_kill+0x194/0x7c0 fs/fs_pin.c:44 mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81 cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366 task_work_run+0x14e/0x250 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [en línea] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 get_signal+0x2576/0x2610 kernel/signal.c:3017 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 bucle de salida al modo usuario kernel/entry/common.c:111 [en línea] preparación de salida al modo usuario include/linux/entry-common.h:329 [en línea] __syscall_salir_al_modo_usuario_work kernel/entry/common.c:207 [en línea] syscall_salir_al_modo_usuario+0x150/0x2a0 kernel/entry/common.c:218 hacer_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entrada_SYSCALL_64_después_de_hwframe+0x77/0x7f RIP: 0033:0x7fee3cb87a6a Código: No se puede acceder a los bytes del código de operación en 0x7fee3cb87a40. RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037 RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a RDX: 0000000000000041 RSI: 000000000000000 RDI: 0000000000000003 RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7 R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500 R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000 Módulos vinculados en: ---[ fin del seguimiento 000000000000000 ]--- RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Código: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Se corrige el error DIO asincrónico del kernel Netfslib debe poder gestionar el error DIO asincrónico iniciado por el kernel que se suministra con una matriz bio_vec[]. Actualmente, debido al indicador async, esto se pasa a netfs_extract_user_iter() que lanza una advertencia y falla porque solo gestiona iteradores IOVEC y UBUF. Esto se puede activar a través de una combinación de cifs y un blockdev de bucle invertido con algo como: mount //my/cifs/share /foo dd if=/dev/zero of=/foo/m0 bs=4K count=1K losetup --sector-size 4096 --direct-io=on /dev/loop2046 /foo/m0 echo hello >/dev/loop2046 Esto hace que aparezca lo siguiente en syslog: ADVERTENCIA: CPU: 2 PID: 109 en fs/netfs/iterator.c:50 netfs_extract_user_iter+0x170/0x250 [netfs] y que la escritura falle. Solucione esto eliminando la comprobación en netfs_unbuffered_write_iter_locked() que hace que las escrituras DIO del kernel asíncronas se gestionen como escrituras del espacio de usuario. Tenga en cuenta que este cambio depende de que el llamador del núcleo mantenga la existencia de la matriz bio_vec (o kvec[] o folio_queue) hasta que se complete la operación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se corrige la invalidación de tlb al realizar un wedging. Si GuC no se carga, el controlador realiza un wedging, pero en el proceso intenta hacer cosas que quizás aún no se hayan inicializado. Esto hace que xe_gt_tlb_invalidation_init() se realice antes: como dice su propia documentación, es una inicialización solo de software y debería haber sido nombrada con el sufijo _early(). Muévelo para que sea llamado por xe_gt_init_early(), de modo que los bloqueos y seqno se inicialicen, evitando un ptr deref NULL al realizar cuñas: xe 0000:03:00.0: [drm] *ERROR* GT0: carga fallida: estado: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01 xe 0000:03:00.0: [drm] *ERROR* GT0: verificación de firma de firmware fallida xe 0000:03:00.0: [drm] *ERROR* CRÍTICO: Xe ha declarado el dispositivo 0000:03:00.0 como cuñado. ... ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 UID: 0 PID: 3908 Comm: modprobe Contaminado: GUW 6.13.0-rc4-xe+ #3 Contaminado: [U]=USER, [W]=WARN Nombre del hardware: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 01/07/2022 RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe] Esto se puede activar fácilmente al presionar el binario GuC para forzar un error de firma. Aún habrá un mensaje adicional, xe 0000:03:00.0: [drm] *ERROR* GT0: Solicitud mmio GuC 0x4100: no hay respuesta 0x4100 pero eso es mejor que una desreferencia de ptr NULL. (seleccionado de el commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: plpmtud_probe_interval: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), por ejemplo cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, ya que este es el único miembro necesario de la estructura 'net', pero eso aumentaría el tamaño de esta corrección, para usar '*data' en todos los lugares donde se use 'net->sctp.probe_interval'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: udp_port: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), p. ej. cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, pero eso aumentaría el tamaño de esta corrección, mientras que 'sctp.ctl_sock' aún necesita ser recuperado de la estructura 'net'.