Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/efistub: use archivo 1:1: mapeo de memoria para PE/COFF sección .compat La sección .compat es una sección PE ficticia que contiene la dirección del punto de entrada de 32 bits de la imagen del kernel de 64 bits si se puede iniciar desde firmware de 32 bits (es decir, CONFIG_EFI_MIXED=y) Esta sección tiene solo 8 bytes de tamaño y solo se hace referencia a ella desde el cargador, por lo que se coloca al final de la memoria. vista de la imagen, para evitar la necesidad de rellenarla a 4k, lo cual es necesario para las secciones que aparecen en el medio de la imagen. Desafortunadamente, esto viola la especificación PE/COFF, e incluso si la mayoría de los cargadores EFI funcionan correctamente (incluida la implementación de referencia de Tianocore), existen cargadores PE que rechazan dichas imágenes, basándose en que tanto las vistas de archivo como de memoria del contenido del archivo deben ser descritos por los encabezados de las secciones de manera monótonamente creciente sin dejar espacios en blanco. Así que reorganice las secciones para evitar este problema. Esto da como resultado una ligera sobrecarga de relleno (< 4k) que se puede evitar si se desea deshabilitando CONFIG_EFI_MIXED (que solo es necesario en casos excepcionales en estos días)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: inet: lee sk->sk_family una vez en inet_recv_error() se llama a inet_recv_error() sin mantener el bloqueo del socket. El socket IPv6 podría mutar a IPv4 con la opción de socket IPV6_ADDRFORM y generar una advertencia de KCSAN.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: atlantic: corrige el mapeo DMA para el anillo PTP hwts. La función aq_ring_hwts_rx_alloc() asigna bytes AQ_CFG_RXDS_DEF adicionales para el anillo PTP HWTS, pero luego el aq_ring_free() genérico no tiene esto en cuenta. Cree y utilice una función específica para liberar el anillo HWTS y solucionar este problema. Seguimiento: [215.351607] ------------[ cortar aquí ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: el controlador de dispositivo se libera Memoria DMA con diferente tamaño [dirección del dispositivo=0x00000000fbdd0000] [tamaño del mapa=34816 bytes] [tamaño de desasignación=32768 bytes] [215.351635] ADVERTENCIA: CPU: 33 PID: 10759 en kernel/dma/debug.c:988 check_unmap+0xa6f/ 0x2360... [215.581176] Seguimiento de llamadas: [215.583632] [215.585745]? show_trace_log_lvl+0x1c4/0x2df [215.590114]? show_trace_log_lvl+0x1c4/0x2df [215.594497]? debug_dma_free_coherent+0x196/0x210 [215.599305]? check_unmap+0xa6f/0x2360 [215.603147]? __advertir+0xca/0x1d0 [215.606391] ? check_unmap+0xa6f/0x2360 [215.610237]? report_bug+0x1ef/0x370 [215.613921]? handle_bug+0x3c/0x70 [215.617423]? exc_invalid_op+0x14/0x50 [215.621269]? asm_exc_invalid_op+0x16/0x20 [215.625480]? check_unmap+0xa6f/0x2360 [215.629331]? mark_lock.part.0+0xca/0xa40 [215.633445] debug_dma_free_coherent+0x196/0x210 [215.638079]? __pfx_debug_dma_free_coherent+0x10/0x10 [215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlántico] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlántico]... [216.127540] ---[fin de seguimiento 6467e5964dd2640b]- -- [ 216.132160] DMA-API: Asignado en: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150 /0x1f0 [atlántico] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlántico] [216.132213] aq_nic_init+0x4a1/0x760 [atlántico]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: evita un posible bucle en nsim_dev_trap_report_work() Muchos informes de syzbot incluyen el siguiente seguimiento [1] Si nsim_dev_trap_report_work() no puede capturar el mutex, debería rearmarse al menos un santiamén después . [1] Envío de NMI desde la CPU 1 a las CPU 0: seguimiento de NMI para la CPU 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: eventos nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [en línea] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [ en línea] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [en línea] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [en línea] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [en línea] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Código: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: ffffbfff258af1e RBX: ffffbfff258af1f RCX: ffffffff8168eda3 RDX: ffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: ffffbfff258af1e R08: 00000000000000000 R09: f ffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000 000000000000(0000) GS: ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR 4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 00000 00000000400 Seguimiento de llamadas: < NMI> instrument_atomic_read include/linux/instrumented.h:68 [en línea] atomic_read include/linux/atomic/atomic-instrumented.h:32 [en línea] queued_spin_is_locked include/asm-generic/qspinlock.h: 57 [en línea] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [en línea] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [en línea] _raw_spin_unlock_irqrestore +0x22/0x70 núcleo /locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [en línea] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/ workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [en línea] Schedule_delayed_work include/linux/workqueue.h :677 [en línea] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 Process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] work_thread+0x8b9/0x1290 núcleo /workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: "wifi: mac80211: improve CSA/ECSA connection refusal". Como se mencionó en el commit anterior, descubrimos rápidamente que algunos AP tienen elementos ECSA atascados en su respuesta de sondeo, por lo que no se pueden usar si intentamos conectarnos mientras se realiza CSA, nunca nos conectaremos a dicho AP. Mejore esta situación verificando más cuidadosamente e ignorando ECSA si cfg80211 ha detectado previamente que el elemento ECSA está atascado en la respuesta de la sonda. Además, permita conectarse a un AP que esté cambiando a un canal que ya esté usando, a menos que esté usando el modo silencioso. En este caso, es posible que tengamos que ajustar el ancho de banda más adelante. Si en realidad está cambiando de canal, es mejor no intentar conectarse en medio de eso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: "wifi: cfg80211: detect stuck ECSA element in probe resp". Recientemente agregamos alguna validación de que no intentamos conectarnos a un AP que se encuentra actualmente en un proceso de cambio de canal, desde entonces es posible que deseemos que el canal esté en silencio o que no podamos conectarnos a tiempo para escuchar el cambio en una baliza. Esto estaba en el commit c09c4f31998b ("wifi: mac80211: no se conecte a un AP mientras esté en un proceso CSA"). Sin embargo, rápidamente recibimos un informe de que esto causó nuevas fallas de conexión, y resulta que el AP al que ahora no podemos conectarnos anuncia permanentemente un anuncio de cambio de canal extendido, incluso en silencio. El AP en cuestión era un Asus RT-AC53, con firmware 3.0.0.4.380_10760-g21a5898. Como primer paso, intente detectar que estamos lidiando con una situación de este tipo, para que mac80211 pueda usarlo más adelante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: xgmac: corrige el manejo del error de seguridad DPP para canales DMA. El commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") verifica e informa errores de seguridad, pero deja sin controlar los errores de paridad de ruta de datos para cada canal en DMA, lo que provoca una tormenta de interrupciones. Solucionelo verificando y borrando el registro DMA_DPP_Interrupt_Status.

En OpenHarmony v4.0.0 y versiones anteriores permiten que un atacante remoto cause DOS mediante una entrada incorrecta.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: implementar la verificación de los límites para la creación del codificador de flujo en la matriz DCN301 'stream_enc_regs' es una matriz de estructuras dcn10_stream_enc_registers. La matriz se inicializa con cuatro elementos, correspondientes a las cuatro llamadas a stream_enc_regs() en el inicializador de la matriz. Esto significa que los índices válidos para esta matriz son 0, 1, 2 y 3. El mensaje de error 'stream_enc_regs' 4 <= 5 a continuación indica que hay un intento de acceder a esta matriz con un índice de 5, que no está disponible. de los límites. Esto podría provocar un comportamiento indefinido. Aquí, eng_id se utiliza como índice para acceder a la matriz stream_enc_regs. Si eng_id es 5, esto daría como resultado un acceso fuera de los límites en la matriz stream_enc_regs. Solucionando así el error de desbordamiento de búfer en dcn301_stream_encoder_create informado por Smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: desbordamiento de búfer 'stream_enc_regs' 4 <= 5

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: agregue prueba NULL para 'generador de sincronización' en 'dcn21_set_pipe()' en "u32 otg_inst = pipe_ctx->stream_res.tg->inst;" pipe_ctx->stream_res.tg podría ser NULL, depende de la persona que llama garantizar que el tg no sea NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: la solución 'panel_cntl' podría ser nula en 'dcn21_set_backlight_level()'. La estructura 'panel_cntl' utilizada para controlar el panel de visualización podría ser nula, desreferenciarla podría conducir a un acceso de puntero nulo. Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 Error de dcn21_set_backlight_level(): previamente asumimos que 'panel_cntl' podría ser nulo (consulte la línea 250)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tipc: verifique el tipo de portador antes de llamar a tipc_udp_nl_bearer_add() syzbot informó la siguiente falla de protección general [1]: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000010: 0000 [#1 ] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x00000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Seguimiento de llamadas: tipc_udp_ nl_bearer_add+ 0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink. c:1052 [en línea] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/ af_netlink.c:1341 [en línea] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0xd 5 /0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x 64 arco/x86/ Entry/common.c:52 [en línea] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b La causa de este problema es que cuando se llama a tipc_nl_bearer_add() con el atributo TIPC_NLA_BEARER_UDP_OPTS, tipc_udp_nl_bear er_añadir () se llama incluso si el portador no es UDP. tipc_udp_is_known_peer() llamado por tipc_udp_nl_bearer_add() supone que el campo media_ptr de tipc_bearer tiene un objeto de tipo udp_bearer, por lo que la función se vuelve loca para los portadores que no son UDP. Este parche soluciona el problema al verificar el tipo de portador antes de llamar a tipc_udp_nl_bearer_add() en tipc_nl_bearer_add().