Vulnerabilidades

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---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: smartpqi: solucione enable_managed_interrupts Corrija el problema de registro de blk-mq con el parámetro del módulo enable_managed_interrupts habilitado. Cuando desactivamos el indicador PCI_IRQ_AFFINITY predeterminado, el controlador debe registrarse con blk-mq usando blk_mq_map_queues(). Actualmente, el controlador está llamando a blk_mq_pci_map_queues(), lo que genera un seguimiento de la pila y posiblemente un comportamiento indefinido. Seguimiento de pila: [7.860089] scsi host2: smartpqi [7.871934] ADVERTENCIA: CPU: 0 PID: 238 en block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [7.889231] Módulos vinculados en: sd_mod t10_pi sg uas smartpqi (+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fusible [7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 No contaminado 4.18.0-372.88.1.el8_6_smartpqi_test .x86_64 #1 [7.944336] Nombre del hardware: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 08/03/2022 [ 7.963026] Cola de trabajo: eventos work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Código: 4 8 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 5 7 49 89 y siguientes 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000 0000000010 [ 7.978284] RDX: 00000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc370 7d38 R09: ffff91929b81ac00 [ 7.978287] R10: 00000000000000001 R11: ffffa95fc3707ac0 R12: 00000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 0 0000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [8.172816] DR0: [ 8.172818] PKRU : 55555554 [8.172819] Seguimiento de llamadas: [8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [8.279302] pqi_ctrl_init+0xacf/0 xc8e [smartpqi] [8.294085]? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.3 51193] proceso_one_work+0x1a7/0x360 [8.364462]? create_worker+0x1a0/0x1a0 [8.379252] work_thread+0x1ce/0x390 [8.392623]? create_worker+0x1a0/0x1a0 [8.406295] kthread+0x10a/0x120 [8.418428]? set_kthread_struct+0x50/0x50 [8.431532] ret_from_fork+0x1f/0x40 [8.444137] ---[ final de seguimiento 1bf0173d39354506 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/qedr: corrija el flujo de error qedr_create_user_qp Evite la siguiente advertencia asegurándose de liberar los recursos asignados en caso de que qedr_init_user_queue() falle. -----------[ cortar aquí ]----------- ADVERTENCIA: CPU: 0 PID: 143192 en drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/ 0xf0 [ib_uverbs] Módulos vinculados en: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd Grace fscache netfs 8 021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fusible drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [última descarga: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: cargado No contaminado 5.14.0-408.el 9.x86_64 #1 Nombre del hardware: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 25/01/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Código: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc 60 EF BANDERAS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 00000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 00000000000039000 R12: ffff8f0d5b36cd80 R13: ff ff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 00000000000000000( 0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7 210002 CR4: 00000000001706f0 Seguimiento de llamadas: ? show_trace_log_lvl+0x1c4/0x2df? show_trace_log_lvl+0x1c4/0x2df? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __advertir+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140? handle_bug+0x3c/0x70? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x8 7c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90? common_interrupt+0x43/0xa0 Entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Código: no se puede acceder a los bytes del código de operación en RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9 200 RSI: 00000000c0181b01 RDI: 00000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 --[ final de seguimiento 888a9b92e04c5c97 ]--

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/srpt: admite la especificación del parámetro srpt_service_guid. Hace que la carga de ib_srpt con este conjunto de parámetros funcione. El comportamiento actual es que configurar ese parámetro mientras se carga el módulo del kernel ib_srpt desencadena el siguiente fallo del kernel: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 Seguimiento de llamadas: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/ 0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: roles: soluciona el problema del puntero NULL al colocar la referencia del módulo. En el diseño actual, el controlador de clase de rol usb obtendrá la referencia del módulo principal usb_role_switch después de que el usuario obtenga el dispositivo usb_role_switch y coloque la referencia después del El usuario puso el dispositivo usb_role_switch. Sin embargo, el dispositivo principal de usb_role_switch se puede eliminar antes de que el usuario coloque usb_role_switch. Si es así, entonces, el problema del puntero NULL se solucionará cuando el usuario coloque la referencia del módulo principal. Esto guardará el puntero del módulo en la estructura de usb_role_switch. Entonces, no necesitamos encontrar el módulo iterando relaciones largas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdns3: corrige la memoria doblemente libre cuando se maneja el paquete cero 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, solicitud 832); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (solicitud->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, solicitud); El controlador agrega una solicitud de paquete cero adicional cuando pone en cola un paquete, cuya longitud mod tamaño máximo del paquete es 0. Cuando se complete la transferencia, ejecute la línea 831, usb_gadget_giveback_request() liberará esta solicitud. La condición 836 es verdadera, por lo que cdns3_gadget_ep_free_request() libera esta solicitud nuevamente. Registro: [1920.140696][ T150] ERROR: KFENCE: lectura de uso después de liberación en cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Lectura de uso después de liberación en 0x000000003d 1cd10b (en kcerca -#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Agregar cheque en la línea 829, omitir llamada usb_gadget_giveback_ request() si tiene una longitud cero adicional solicitud de paquete. No es necesario llamar a usb_gadget_giveback_request() porque está asignado en este controlador.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: cdns3: uso de memoria fijo después de liberar en cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->lista); ... 'priv_req' en realidad es gratuito en cdns3_gadget_ep_free_request(). Pero list_del_init() usa priv_req->list después. [ 1542.642868][ T534] ERROR: KFENCE: lectura de uso después de liberación en __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Lectura de uso después de liberación en 0x000000009ed0ba99 (en kfence-#3 ): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0x e4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839] [ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Mueva list_del_init() antes de cdns3_gadget_ep_free_request() para resolver este problema.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ARM: ep93xx: Agregar terminador a gpiod_lookup_table Sin el terminador, si se pasa un con_id a gpio_find() que no existe en la tabla de búsqueda, la función no dejará de repetirse correctamente y eventualmente causará un oops

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: l2tp: pasa la longitud correcta del mensaje a ip6_append_data l2tp_ip6_sendmsg necesita evitar tener en cuenta el encabezado de transporte dos veces al unir más datos en un skbuff ya parcialmente ocupado. Para gestionar esto, verificamos si skbuff contiene datos usando skb_queue_empty al decidir cuántos datos agregar usando ip6_append_data. Sin embargo, el código que realizó el cálculo era incorrecto: ulen = len + skb_queue_empty(&sk->sk_write_queue)? transhdrlen : 0; ...debido a la precedencia del operador C, esto termina configurando ulen en transhdrlen para mensajes con una longitud distinta de cero, lo que resulta en paquetes corruptos en el cable. Agregue paréntesis para corregir el cálculo de acuerdo con la intención original.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: virtio/akcipher: corrige el desbordamiento de pila en memcpy sizeof(struct virtio_crypto_akcipher_session_para) es menor que sizeof(struct virtio_crypto_op_ctrl_req::u), copiar más bytes de la variable de pila provoca el desbordamiento de pila. Clang informa este problema mediante comandos: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_mirred: no anula retval si ya perdimos el skb. Si estamos redirigiendo el skb y aún no hemos llamado a tcf_mirred_forward(), necesitamos para decirle al núcleo que suelte el skb configurando el código de retección en SHOT. Sin embargo, si hemos llamado a tcf_mirred_forward(), el skb está fuera de nuestras manos y devolver SHOT conducirá a UaF. Mueva la anulación de recuperación a la ruta de error que realmente la necesita.

Una vulnerabilidad en la interfaz de administración basada en web de Cisco Identity Services Engine (ISE) podría permitir que un atacante remoto no autenticado lleve a cabo un ataque de cross-site request forgery (CSRF) y realice acciones arbitrarias en un dispositivo afectado. Esta vulnerabilidad se debe a protecciones CSRF insuficientes para la interfaz de administración basada en web de un dispositivo afectado. Un atacante podría aprovechar esta vulnerabilidad persuadiendo a un usuario de la interfaz para que siga un enlace manipulado. Un exploit exitoso podría permitir al atacante realizar acciones arbitrarias en el dispositivo afectado con los privilegios del usuario objetivo.