Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet-fc: evita el punto muerto al eliminar la ruta de asociación Al eliminar una asociación, la ruta de cierre se bloquea porque intentamos vaciar el nvmet_wq anidado. Evite este punto muerto al diferir el trabajo colocado en su propio elemento de trabajo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: nvidia-shield: agregar comprobaciones de puntero nulo faltantes a la inicialización del LED devm_kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero. [jkosina@suse.com: modificar un poco el registro de cambios]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: ti: edma: agregue algunas comprobaciones de puntero nulo a edma_probe devm_kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: tipos de enteros fijos y ubicaciones de verificación nula [por qué]: problemas solucionados: - comparación con un tipo de entero más amplio en condición de bucle que puede causar bucles infinitos - desreferencia del puntero antes cheque nulo

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: arp: Evita el desbordamiento en arp_req_get(). syzkaller informó una escritura desbordada en arp_req_get(). [0] Cuando se emite ioctl(SIOCGARP), arp_req_get() busca una entrada vecina y copia neigh->ha para estructurar arpreq.arp_ha.sa_data. El arp_ha aquí es struct sockaddr, no struct sockaddr_storage, por lo que el búfer sa_data tiene solo 14 bytes. En el siguiente símbolo, se desbordan 2 bytes al siguiente campo int, arp_flags. Inicializamos el campo justo después de memcpy(), por lo que no es un problema. Sin embargo, cuando dev->addr_len es mayor que 22 (por ejemplo, MAX_ADDR_LEN), se sobrescribe arp_netmask, que podría configurarse como htonl(0xFFFFFFFFUL) en arp_ioctl() antes de llamar a arp_req_get(). Para evitar el desbordamiento, limitemos la longitud máxima de memcpy(). Tenga en cuenta que el commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") simplemente silenció a syzkaller. [0]: memcpy: escritura detectada en todos los campos (tamaño 16) de un solo campo "r->arp_ha.sa_data" en net/ipv4/arp.c:1128 (tamaño 14) ADVERTENCIA: CPU: 0 PID: 144638 en net /ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Módulos vinculados en: CPU: 0 PID: 144638 Comm: syz-executor.4 No contaminado 6.1.74 #31 Nombre de hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 01/04/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Código: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 00000000000000000 RBX: ffff88803a815000 RCX: 0000000000000 000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 00000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 0000 7f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4 : 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000000 0000000400 PKRU: 55555554 Seguimiento de llamadas: arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl.c:856 [en línea] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x37/0x90 arch/x86/ entrada/common.c:81 entrada_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Código: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 0000024 6 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX : 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 00000000000000003 RBP: 00007f172b2d3493 R08: 0 000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: devlink: corrige posibles pérdidas de memoria y use-after-free en devlink_init() La estructura de operaciones pernet para el subSYSTEM debe registrarse antes de registrar la familia netlink genérica. Realice una cancelación del registro en caso de que el registro no sea exitoso.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6:sr: corrige posible use-after-free y null-ptr-deref La estructura de operaciones pernet para el subsystem debe registrarse antes de registrar la familia netlink genérica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: aumenta el tamaño del búfer en afs_update_volume_status() La longitud máxima del volumen->valor vid es de 20 caracteres. Por lo tanto, aumente el tamaño de idbuf[] hasta 24 para evitar el desbordamiento. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [DH: En realidad, es 20 + NUL, así que auméntalo a 24 y usa snprintf()]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corrección de ejecucións entre bpf_timer_cancel_and_free y bpf_timer_cancel La siguiente ejecución es posible entre bpf_timer_cancel_and_free y bpf_timer_cancel. Dirigirá una UAF en el temporizador->temporizador. bpf_timer_cancel(); spin_lock(); t = temporizador->tiempo; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = temporizador->temporizador; temporizador->temporizador = NULL; spin_unlock(); hrtimer_cancel(&t->temporizador); klibre(t); /* UAF en t */ hrtimer_cancel(&t->timer); En bpf_timer_cancel_and_free, este parche libera el temporizador->temporizador después de un período de gracia de rcu. Esto requiere una adición de rcu_head a "struct bpf_hrtimer". Otro kfree(t) ocurre en bpf_timer_init, esto no necesita un kfree_rcu porque todavía está bajo spin_lock y otros aún no han visible el temporizador->temporizador. En bpf_timer_cancel, se agrega rcu_read_lock() porque este asistente puede usarse en un contexto de sección no crítica para rcu (por ejemplo, desde un programa bpf que se puede dormir). Se han auditado otros usos de temporizador->temporizador en helpers.c, bpf_timer_cancel() es el único lugar donde se usa temporizador->temporizador fuera de spin_lock. Otra solución considerada es marcar una bandera t-> en bpf_timer_cancel y borrarla una vez finalizado hrtimer_cancel(). En bpf_timer_cancel_and_free, está ocupado esperando a que se borre la bandera antes de kfree(t). Este parche incluye una solución sencilla y libera el temporizador->temporizador después de un período de gracia de rcu.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries/iommu: la adición de DLPAR no inicializa completamente pci_controller Cuando se agrega dinámicamente un dispositivo PCI, el kernel falla con una desreferencia del puntero NULL: ERROR: desreferencia del puntero NULL del kernel activado leído en 0x00000030 Dirección de instrucción errónea: 0xc0000000006bbe5c Vaya: acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 Módulos NUMA pSeries vinculados en: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_r pcgss nfsv4 dns_resolver nfs lockd gracia fscache netfs xsk_diag vinculación nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5 _ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod CPU fusible : 17 PID: 2685 Comm: drmgr No contaminado 6.7.0-203405+ #66 Nombre de hardware: IBM,9080-HEX POWER10 (sin procesar) 0x800200 0xf000006 de:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006b be5c LR : c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 No contaminado (6.7.0-203405+) MSR: 8000000000009033 CR: 2400 2220 XER: 20040006 CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0 ... NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Seguimiento de llamadas: iommu_init_device+0x26c/0x318 (no confiable) iommu_device_ enlace+0x5c/0x118 iommu_init_device+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+ 0x44/0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_s can_pci_dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+ 0xb8/0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b 0/0x290 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+ 0x124/0x330 system_call_vectored_common+0x15c/0x2ec el commit a940904443e4 ("powerpc/iommu: agregue iommu_ops para informar capacidades y permitir dominios de bloqueo") rompió la adición DLPAR de dispositivos PCI. Lo anterior agregó la estructura iommu_device a pci_controller. Durante el arranque del SYSTEM, se descubren dispositivos PCI y esta estructura iommu_device recién agregada se inicializa mediante una llamada a iommu_device_register(). Durante la adición DLPAR de un dispositivo PCI, se asigna una nueva estructura pci_controller pero no se realizan llamadas a la interfaz iommu_device_register(). La solución es registrar también el dispositivo iommu durante la adición de DLPAR.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: act_mirred: use el trabajo pendiente para el ingreso duplicado. La prueba que Davide agregó en el compromiso ca22da2fbd69 ("act_mirred: use el trabajo pendiente para llamadas anidadas para el ingreso duplicado") bloquea nuestras máquinas virtuales de prueba. aproximadamente cada 10 ejecuciones, con el conocido punto muerto tcp_v4_rcv -> tcp_v4_rcv informado por lockdep. El problema descrito anteriormente por Davide (ver Enlace) es que si invertimos el flujo de tráfico con la redirección (salida -> entrada) podemos llegar al mismo socket que generó el paquete. Y es posible que todavía estemos sosteniendo el bloqueo del enchufe. La solución común a estos puntos muertos es colocar el paquete en el trabajo pendiente de Rx, en lugar de ejecutar la ruta de Rx en línea. Haga eso para todas las reversiones de salida -> entrada, no solo una vez que comenzamos a anidar llamadas reflejadas. En el pasado, existía la preocupación de que la dirección indirecta del trabajo pendiente provocara la pérdida de informes de errores o estadísticas menos precisas. Pero la solución actual no parece solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dccp/tcp: Unhash sk de ehash para error de asignación de tb2 después de check_estalblished(). syzkaller informó una advertencia [0] en inet_csk_destroy_sock() sin reproducción. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); Sin embargo, el registro del syzkaller insinuó que connect() falló justo antes de la advertencia debido a FAULT_INJECTION. [1] Cuando se llama a connect() para un socket independiente, buscamos un puerto efímero disponible. Si existe un depósito bhash para el puerto, llamamos a __inet_check_establecido() o __inet6_check_establecido() para verificar si el depósito es reutilizable. Si es reutilizable, agregamos el socket en ehash y configuramos inet_sk(sk)->inet_num. Luego, buscamos el depósito bhash2 correspondiente e intentamos asignarlo si no existe. Aunque rara vez ocurre en el uso real, si la asignación falla, debemos revertir los cambios mediante check_establecido(). De lo contrario, un enchufe desconectado podría ocupar ilegalmente una entrada ehash. Tenga en cuenta que no volvemos a colocar tw en ehash porque es posible que sk ya haya respondido a un paquete para tw y sería mejor liberar tw antes bajo tal presión de memoria. [0]: ADVERTENCIA: CPU: 0 PID: 350830 en net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Módulos vinculados en: Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996 ), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Código: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e 7 be 03 00 00 00 e8 05 RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40 RDX: ffff88806e 46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8 RBP: ffff88811755c880 R08: 0000000000000003 R09: 00000000000000000 R10: 0000000000009e78 R11: 00 00000000000000 R12: ffff88811755c8e0 R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000 FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knl GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0 PKRU: 5555 Llamada 5554 Seguimiento: ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) dccp_close (net/dccp/proto.c:1078) inet_release (net/ipv4/af_inet.c:434) __sock_release (net/socket.c:660) sock_close (net/ socket.c:1423) __fput (fs/file_table.c:377) __fput_sync (fs/file_table.c:462) __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7f03e53852bb Código: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3 5 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44 RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 00000000000000003 RAX: ffffffffffffffda RBX: 00000000000000004 RCX: 00007f03e53852bb RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003 RBP: 000000000000000000 R08: 0000000000000000 R09: 000000000000167c R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000 R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e431 70 [1]: FAULT_INJECTION: forzando un fallo. nombre failslab, intervalo 1, probabilidad 0, espacio 0, tiempos 0 CPU: 0 PID: 350833 Comm: syz-executor.1 No contaminado 6.7.0-12272-g2121c43f88f5 #9 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996 ), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl---truncado---