Vulnerabilidades

En tbd de tbd, existe una posible corrupción de memoria debido a un use after free. Esto podría conducir a una escalada local de privilegios sin necesidad de permisos de ejecución adicionales. La interacción del usuario no es necesaria para la explotación.

El kernel de Android permite la divulgación de información.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: corrige una corrupción de memoria iwl_fw_ini_trigger_tlv::data es un puntero a un __le32, lo que significa que si copiamos a iwl_fw_ini_trigger_tlv::data + offset mientras el offset está en bytes, escribiremos más allá del búfer.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xsk: corrige el uso de asistentes BPF de múltiples búfer para ZC XDP Actualmente, cuando el paquete se reduce a través de bpf_xdp_adjust_tail() y el tipo de memoria está configurado en MEM_TYPE_XSK_BUFF_POOL, se produce una desreferencia de ptr nula: [1136314.192256] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000034 [1136314.203943] #PF: acceso de lectura del supervisor en modo kernel [1136314.213768] #PF: error_code(0x0000) - página no presente [1136314.223550] PGD 0 P4D 0 [113631 4.230684] Ups: 0000 [#1] PREEMPT SMP NOPTI [1136314.239621] CPU: 8 PID: 54203 Comm: xdpsock Not tainted 6.6.0+ #257 [1136314.250469] Nombre de hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.0 31920191559 03/19 /2019 [1136314.265615] RIP: 0010:__xdp_return+0x6c/0x210 [1136314.274653] Código: ad 00 48 8b 47 08 49 89 f8 a8 01 0f 85 9b 01 00 00 0f 1f 44 0 0 00 f0 41 y siguientes 48 34 75 32 4c 89 c7 e9 79 cd 80 ff 83 fe 03 75 17 41 34 01 0f 85 02 01 00 00 48 89 cf e9 22 cc 1e 00 e9 3d d2 86 [1136314.302907] RSP: 0018:ffffc900089f 8db0 EFLAGS: 00010246 [1136314.312967] RAX : ffffc9003168aed0 RBX: ffff8881c3300000 RCX: 0000000000000000 [1136314.324953] RDX: 00000000000000000 RSI: 0000000000000003 RDI: ffffc900316 8c000 [1136314.336929] RBP: 0000000000000ae0 R08: 0000000000000002 R09: 0000000000010000 [1136314.348844] R10: ffffc9000e495000 R11: 000 0000000000040 R12: 00000000000000001 [1136314.360706] R13: 00000000000000524 R14: ffffc9003168aec0 R15: 0000000000000001 [1136314.373298] FS: 00007f8df8bbcb80(0000) GS:ffff8897e0e00000(0000) knlGS:0000000000000000 [1 136314.386105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1136314.396532] CR2: 00000000000000034 CR3: 00000001aa912002 CR4: 00000000007706f0 [1136314.408377] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 [1136314.420173] DR3: 00000000000 00000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1136314.431890] PKRU: 55555554 [1136314.439143] Seguimiento de llamadas: [1136314.446058] [1136314.452465 ] ? __morir+0x20/0x70 [1136314.459881] ? page_fault_oops+0x15b/0x440 [1136314.468305] ? exc_page_fault+0x6a/0x150 [1136314.476491] ? asm_exc_page_fault+0x22/0x30 [1136314.484927] ? __xdp_return+0x6c/0x210 [1136314.492863] bpf_xdp_adjust_tail+0x155/0x1d0 [1136314.501269] bpf_prog_ccc47ae29d3b6570_xdp_sock_prog+0x15/0x60 [1136314 .511263] ice_clean_rx_irq_zc+0x206/0xc60 [hielo] [1136314.520222] ? ice_xmit_zc+0x6e/0x150 [hielo] [1136314.528506] ice_napi_poll+0x467/0x670 [hielo] [1136314.536858] ? ttwu_do_activate.constprop.0+0x8f/0x1a0 [1136314.546010] __napi_poll+0x29/0x1b0 [1136314.553462] net_rx_action+0x133/0x270 [1136314.561619] __do_softirq+0xbe/0x2 8e [1136314.569303] do_softirq+0x3f/0x60 Esto proviene de la llamada __xdp_return() con xdp_buff argumento pasado como NULL que se supone que debe ser consumido por la llamada xsk_buff_free(). Para solucionar esto correctamente, en el caso de ZC, se debe extraer de xskb_list un nodo que represente el fragmento que se está eliminando. Introduzca ayudantes xsk apropiados para realizar dicha operación de nodo y utilícelos en consecuencia dentro de bpf_xdp_adjust_tail().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs, fscache: Prevenir Ups en fscache_put_cache() Esta función desreferencia "caché" y luego verifica si es IS_ERR_OR_NULL(). Primero verifique y luego elimine la referencia.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/rds: Corrección de UBSAN: array-index-out-of-bounds en rds_cmsg_recv El bloqueo de Syzcaller UBSAN ocurre en rds_cmsg_recv(), que dice inc->i_rx_lat_trace[j + 1] con índice 4 (3 + 1), pero con tamaño de matriz de 4 (RDS_RX_MAX_TRACES). Aquí 'j' se asigna desde rs->rs_rx_trace[i] y, a su vez, desde trace.rx_trace_pos[i] en rds_recv_track_latency(), con ambas matrices de tamaño 3 (RDS_MSG_RX_DGRAM_TRACE_MAX). Así que arregle la verificación de los límites fuera de uno en rds_recv_track_latency() para evitar un posible fallo en rds_cmsg_recv(). Encontrado por syzcaller: ================================================ =================== UBSAN: índice de matriz fuera de los límites en net/rds/recv.c:585:39 el índice 4 está fuera de rango para el tipo 'u64 [4]' CPU: 1 PID: 8058 Comm: syz-executor228 No contaminado 6.6.0-gd2f51b3516da #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/ Seguimiento de llamadas de 2014: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [en línea] __ubsan_handle_out_of_bounds+0xd5/0x130 lib/ubsan. c:348 rds_cmsg_recv+0x60d/0x700 net/rds/recv.c:585 rds_recvmsg+0x3fb/0x1610 net/rds/recv.c:716 sock_recvmsg_nosec net/socket.c:1044 [en línea] sock_recvmsg+0xe2/0x1 60 netos/toma .c:1066 __sys_recvfrom+0x1b6/0x2f0 net/socket.c:2246 __do_sys_recvfrom net/socket.c:2264 [en línea] __se_sys_recvfrom net/socket.c:2260 [en línea] __x64_sys_recvfrom+0xe0/0x1b0 net/socket .c:2260 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x63/0x6b =============== ==================================================== ==

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tcp: asegúrese de iniciar los spinlocks de Accept_queue una vez. Cuando ejecuto el programa C de reproducción de syz localmente, causa el siguiente problema: pvqspinlock: ¡el bloqueo 0xffff9d181cd5c660 tiene un valor corrupto 0x0! ADVERTENCIA: CPU: 19 PID: 21160 en __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Nombre del hardware: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt .h :508) Código: 73 56 3a ff 90 c3 cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 00000 00000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 00000000000000000 R13: ffff9d181cd5c660 R14: ffff9d181 3a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Seguimiento de llamadas: _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c: 1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234 ) __netif_receive_skb_one_core (net/core/dev.c:5529) Process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) __local_bh_enable_ip (kernel/softirq.c: 381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release _calcetín (. /include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/ af_inet.c:702) inet_stream_connect (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect (net/socket.c:2073 net/ socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S: 129) QEPD: 0033:0x7fa10ff05a3d Código: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4 c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007FA110183E20 R08: 000000000000000000 R09: 000000000000000000 R10: 0000000000000000000000000000000000000000202 R12: 00007FA1101846440000000000000000000000000000000000000000000000000000000000000SEN 00007FA10FE8B060 R15: 00007FFFF73E23B20 El proceso de activación del problema se analiza de la siguiente manera: subhifique un subproceso b tcp_v4_rcv / /recibir acuse de recibo del paquete TCP inet_shutdown tcp_check_req tcp_disconnect //desconectar calcetín... tcp_set_state(sk, TCP_CLOSE) inet_csk_complete_hashdance... inet_csk_reqsk_queue_add ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrige el acceso ilegal a rmb_desc en el volcado de conexiones SMC-D Se encontró un bloqueo al volcar conexiones SMC-D. Se puede reproducir mediante los siguientes pasos: - ejecute la prueba nginx/wrk: smc_run nginx smc_run wrk -t 16 -c 1000 -d -H 'Conexión: Cerrar' - volcar continuamente las conexiones SMC-D en paralelo: watch -n 1 'smcss -D' ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: cargado Contaminado: GE 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+ 0x5e5/0x620 [smc_diag] Seguimiento de llamadas: ? __morir+0x24/0x70 ? page_fault_oops+0x66/0x150? exc_page_fault+0x69/0x140? asm_exc_page_fault+0x26/0x30? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+ 0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____s ys_sendmsg+0x24e/0x300? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160? do_read_fault+0x5f/0x100? do_fault+0xb0/0x110? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Es posible que la conexión esté en proceso de establecerse cuando la volcamos. Se supone que la conexión ha sido registrada en un grupo de enlaces por smc_conn_create() pero rmb_desc aún no ha sido inicializado por smc_buf_create(), lo que provoca el acceso ilegal a conn->rmb_desc. Así que solucionelo comprobando antes del volcado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: limpieza: evita el use-after-free cuando la longitud del fragmento no está alineada con 64 K [ERROR] Hay un informe de error que indica que, en un btrfs convertido a ext4, la limpieza conduce a varios problemas, que incluyen: - Errores "no se puede encontrar el mapa de fragmentos" Información BTRFS (dispositivo vdb): limpieza: iniciado en el devid 1 BTRFS crítico (dispositivo vdb): no se puede encontrar el mapa de fragmentos para la longitud lógica 2214744064 4096 BTRFS crítico (dispositivo vdb): No se puede encontrar el mapa de fragmentos para la longitud lógica 2214744064 45056. Esto provocaría errores irreparables. - Informes KASAN de uso gratuito: =========================================== ========================= ERROR: KASAN: slab-use-after-free en __blk_rq_map_sg+0x18f/0x7c0 Lectura de tamaño 8 en la dirección ffff8881013c9040 por tarea btrfs/909 CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 2023.11-2 24/12/2023 Seguimiento de llamadas : dump_stack_lvl+0x43/0x60 print_report+0xcf/0x640 kasan_report+0xa6/0xd0 __blk_rq_map_sg+0x18f/0x7c0 virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02ed fad39bb9ddee07dcdaff] virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] blk_mq_flush_plug_list.part. 0+0x780/0x860 __blk_flush_plug+0x1ba/0x220 blk_finish_plug+0x3b/0x60 submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Flush_scrub_stripes+0x38 e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] Scrub_chunk+0x178/0x200 [btrfs e579 87a360cama82fe8756dcd3e0de5406ccfe965 ] Scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btr fs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] __x64_sys_ioctl+0xbd/0x100 do_syscall_64+0x5d/0xe0 Entry_SYSCALL_64_after_hwframe+0x63/0x6b QEPD: 0033:0x7f47e5e0952b - Fallo , principalmente debido al use-after-free anterior [CAUSA] El fs convertido tiene el siguiente diseño de fragmento de datos: clave del elemento 2 (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 tamaño del elemento 80 longitud 86016 propietario 2 stripe_len 65536 tipo DATOS|single Para el bytenr lógico anterior 2214744064 , está al final del fragmento (2214658048 + 86016 = 2214744064). Esto significa que btrfs_submit_bio() dividiría la biografía y activaría la función endio para ambas mitades. Sin embargo, Scrub_submit_initial_read() solo esperaría que la función endio se llamara una vez, ya no. Esto significa que la primera función endio ya liberaría bbio::bio, dejando libre el bvec, por lo que la segunda llamada a endio conduciría a use-after-free. [FIX] - Asegúrese de que Scrub_read_endio() solo actualice los bits en su rango. Dado que podemos leer menos de 64 K al final del fragmento, no debemos tocar los bits más allá del límite del fragmento. - Asegúrese de que Scrub_submit_initial_read() solo lea el rango de fragmentos. Esto se hace calculando el número real de sectores que necesitamos leer y agregando sector por sector a la biografía. Afortunadamente, la ruta de reparación de lectura de limpieza no necesitará correcciones adicionales: - Scrub_stripe_submit_repair_read() Con las correcciones anteriores, no actualizaremos el bit de error para el rango más allá del fragmento, por lo tanto, Scrub_stripe_submit_repair_read() nunca debería enviar ninguna lectura más allá del fragmento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc/task_mmu: mover el mecanismo de notificación mmu dentro del bloqueo mm Mueva el mecanismo de notificación mmu dentro del bloqueo mm para evitar condiciones de ejecución en otros componentes que dependen de él. El notificador invalidará el rango de memoria. Dependiendo del número de iteraciones, se invalidarían diferentes rangos de memoria. Este parche eliminaría la siguiente advertencia: ADVERTENCIA: CPU: 0 PID: 5067 en arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/ x86/kvm/../../../virt/kvm/kvm_main.c:734 No hay cambios de comportamiento ni de rendimiento con este parche cuando no hay ningún componente registrado con el notificador mmu. [akpm@linux-foundation.org: reduzca el alcance del `rango', según Sean]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrige el orden libre de carga del módulo. Orden inverso de las llamadas kfree para resolver el error de use-after-free.