Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/xe_devcoredump: marque NULL antes de las asignaciones. Asigne 'xe_devcoredump_snapshot *' y 'xe_device *' solo si 'coredump' no es NULL. v2: corrige los mensajes de confirmación. v3: definir variables antes del código. (Ashutosh/Jose) v4: eliminar la verificación de retorno para coredump_to_xe. (José/Rodrigo) v5 - Modificar mensaje de confirmación engañoso. (Matt)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ionic: corrige el pánico del kernel debido al manejo de múltiples búfer Actualmente, ionic_run_xdp() no maneja correctamente los paquetes de múltiples búfer para XDP_TX y XDP_REDIRECT. Cuando se recibe una trama gigante, ionic_run_xdp() primero crea una trama xdp con todas las páginas necesarias en el descriptor rx. Y si la acción es XDP_TX o XDP_REDIRECT, debería desasignar dma-mapping y restablecer el puntero de página a NULL para todas las páginas, no solo la primera. Pero no es así para las páginas SG. Por lo tanto, las páginas SG se reutilizarán inesperadamente. Eventualmente causa pánico en el kernel. Vaya: fallo de protección general, probablemente para la dirección no canónica 0x504f4e4dbebc64ff: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.10.0-rc3+ #25 RIP: 0010:xdp_return_frame+0x42/ 0x90 Código: 01 75 12 5b 4c 89 e6 5d 31 c9 41 5c 31 d2 41 5d e9 73 fd ff ff 44 8b 6b 20 0f b7 43 0a 49 81 ed 68 01 00 00 49 29 c5 49 01 fd 41> 80 7d0 RSP: 0018:ffff99d00122ce08 EFLAGS: 00010202 RAX: 0000000000005453 RBX: ffff8d325f904000 RCX: 00000000000000001 RDX: 00000000670e1000 RSI 000 000011f90d000 RDI: 504f4e4d4c4b4a49 RBP: ffff99d003907740 R08: 0000000000000000 R09: 00000000000000000 R10: 000000011f90d000 R11: 00000000000 R12: ffff8d325f904010 R13: 504f4e4dbebc64fd R14: ffff8d3242b070c8 R15: ffff99d0039077c0 FS: 0000000000000000(0000) GS:ffff8d399f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 050033 CR2: 00007f41f6c85e38 CR3: 000000037ac30000 CR4: 00000000007506f0 PKRU: 55555554 Seguimiento de llamadas: ? die_addr+0x33/0x90? exc_general_protection+0x251/0x2f0? asm_exc_general_protection+0x22/0x30? xdp_return_frame+0x42/0x90 ionic_tx_clean+0x211/0x280 [ionic 15881354510e6a9c655c59c54812b319ed2cd015] ionic_tx_cq_service+0xd3/0x210 [ionic 15881354510e6a9c65 5c59c54812b319ed2cd015] ionic_txrx_napi+0x41/0x1b0 [ionic 15881354510e6a9c655c59c54812b319ed2cd015] __napi_poll.constprop.0+0x29/0x1b0 net_rx_action+0x2c4/0x 350 handle_softirqs+0xf4/ 0x320 irq_exit_rcu+0x78/0xa0 interrupción_común+0x77/0x90

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: inicialice nfsd_info.mutex anticipadamente. svc_pool_stats_start() puede eliminar la referencia a nfsd_info.mutex inmediatamente después de crear la nueva red. Actualmente, esto puede provocar un error. Mueva la inicialización antes antes de que se pueda desreferenciarla.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la falla de DIO debido a créditos de transacción insuficientes. El código en ocfs2_dio_end_io_write() estima el número de créditos de transacción necesarios usando ocfs2_calc_extend_credits(). Sin embargo, esto no tiene en cuenta que el IO podría ser arbitrariamente grande y contener un número arbitrario de extensiones. Las manipulaciones del árbol de extensión a menudo extienden la transacción actual, pero no en todos los casos. Por ejemplo, si solo tenemos extensiones de un solo bloque en el árbol, ocfs2_mark_extent_write() terminará llamando a ocfs2_replace_extent_rec() todo el tiempo y nunca extenderemos la transacción actual y eventualmente agotaremos todos los créditos de la transacción si el IO contiene muchas extensiones de un solo bloque. Una vez que eso sucede, se activa un WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) en jbd2_journal_dirty_metadata() y posteriormente OCFS2 cancela en respuesta a este error. En realidad, esto fue provocado por uno de nuestros clientes en un sistema de archivos OCFS2 muy fragmentado. Para solucionar el problema, asegúrese de que la transacción siempre tenga suficientes créditos para una inserción de extensión antes de cada llamada de ocfs2_mark_extent_writing(). Heming Zhao dijo: ------ PÁNICO: "Pánico del kernel - no se sincroniza: OCFS2: (dispositivo dm-1): pánico forzado después del error" PID: xxx TAREA: xxxx CPU: 5 COMANDO: "SubmitThread-CA" # 0 machine_kexec en ffffffff8c069932 #1 __crash_kexec en ffffffff8c1338fa #2 pánico en ffffffff8c1d69b9 #3 ocfs2_handle_error en ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort en ffffffffc0c88387 #5 ocfs2_journal_dirty en ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent en ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag en ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_writing en ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write en ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io en ffffffffc0c2c0f5 [ocfs2] #11 completo en ffffffff8c2b9fa7 #12 do_blockdev_direct_IO en ffffffff8c2bc09f #13 ocfs2_direct_IO en ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write en ffffffff8c1dcf14 #15 __generic_file_write_iter en ffffffff8c1dd07b #16 ocfs2_file_write_iter en ffffffffc0c49f1f [ocfs2] #17 aio_write en ffffffff8c2cc72e #18 kmem_cache_alloc en ffffffff8c248dde #19 _enviar en ffffffff8c2ccada #20 do_syscall_64 en ffffffff8c004984 #21 Entry_SYSCALL_64_after_hwframe en ffffffff8c8000ba

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/restrack: corrige una posible dirección de acceso no válida. El kern_name de la estructura rdma_restrack_entry se configuró en KBUILD_MODNAME en ib_create_cq(), mientras que si el módulo salía pero olvidaba esta rdma_restrack_entry, causaría una dirección no válida. acceda en rdma_restrack_clean() cuando imprima el propietario de este rdma_restrack_entry. Este código se utiliza para ayudar a encontrar una versión de PD olvidada en uno de los ULP. Pero ya no es necesario, así que elimínelos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xdp: Eliminar WARN() de __xdp_reg_mem_model() syzkaller informa una advertencia en __xdp_reg_mem_model(). La advertencia ocurre solo si __mem_id_init_hash_table() devuelve un error. Devuelve el error en dos casos: 1. falla la asignación de memoria; 2. rhashtable_init() falla cuando algunos campos de la estructura rhashtable_params no se inicializan correctamente. El segundo caso no puede ocurrir ya que hay una estructura estática const rhashtable_params con campos válidos. Por lo tanto, la advertencia sólo se activa cuando hay un problema con la asignación de memoria. Por lo tanto, no tiene sentido utilizar WARN() para manejar este error y se puede eliminar de forma segura. ADVERTENCIA: CPU: 0 PID: 5065 en net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 CPU: 0 PID: 5065 Comm: syz-executor883 No contaminado 6.8.0-syzkaller -05271-gf99c5f563c17 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 Seguimiento de llamadas: xdp_reg_mem_model+0x22/ 0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [en línea] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_ ejecutar.c: 1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [en línea] pf kernel/bpf/syscall.c :5736 [en línea] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 Encontrado por el Centro de verificación de Linux (linuxtesting.org) con syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: corrige la desreferencia del puntero NULL en gfs2_log_flush En gfs2_jindex_free(), establezca sdp->sd_jdesc en NULL bajo el bloqueo de descarga de registros para proporcionar exclusión contra gfs2_log_flush(). En gfs2_log_flush(), verifique si sdp->sd_jdesc no es NULL antes de desreferenciarlo. De lo contrario, podríamos encontrarnos con una desreferencia de puntero NULL cuando el trabajo de glock pendiente se ejecuta con un desmontaje (glock_work_func -> run_queue -> do_xmote -> inode_go_sync -> gfs2_log_flush).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: omitir la tubería si el idx de la tubería no está configurado correctamente [por qué] El controlador falla cuando el idx de la tubería no está configurado correctamente [cómo] Agregar código para omitir la tubería cuyo idx no está configurado correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: agregue una verificación NULL en xe_ttm_stolen_mgr_init Agregue una verificación explícita para garantizar que mgr no sea NULL.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/xe: soluciona el posible desbordamiento de enteros en el cálculo del tamaño de la página. Transmite explícitamente tbo->page_alignment a u64 antes del cambio de bits para evitar el desbordamiento al asignar a min_page_size.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: bpf: Tener en cuenta el retorno de set_memory_rox() con bpf_jit_binary_lock_ro() set_memory_rox() puede fallar, dejando la memoria desprotegida. Verifique la devolución y el rescate cuando bpf_jit_binary_lock_ro() devuelva un error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ionic: usa dev_consume_skb_any fuera de napi. Si no estamos en un contexto de softirq de NAPI, debemos tener cuidado con cómo llamamos a napi_consume_skb(), específicamente debemos llamarlo con Budget==0 para indicarle que no estamos en un contexto seguro. Esto se encontró mientras se ejecutaban algunas pruebas de estrés de configuración del tráfico y se ejecutaba un bucle de configuración de cola de cambios, y apareció esta nota curiosa: [4371.402645] ERROR: usar smp_processor_id() en código interrumpible [00000000]: ethtool/20545 [4371.402897] la persona que llama es napi_skb_cache_put+0x16/0x80 [ 4371.403120] CPU: 25 PID: 20545 Comm: ethtool Kdump: loaded Tainted: G OE 6.10.0-rc3-netnext+ #8 [ 4371.403302] Nombre de hardware: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen 10, BIOSU32 23/01/2021 [ 4371.403460] Seguimiento de llamadas: [ 4371.403613] [ 4371.403758] dump_stack_lvl+0x4f/0x70 [ 4371.403904] check_preemption_disabled+0xc1/0xe0 [ 4371.40405 1] napi_skb_cache_put+0x16/0x80 [ 4371.404199] ionic_tx_clean+0x18a/0x240 [ iónico] [4371.404354] ionic_tx_cq_service+0xc4/0x200 [iónico] [4371.404505] ionic_tx_flush+0x15/0x70 [iónico] [4371.404653]? ionic_lif_qcq_deinit.isra.23+0x5b/0x70 [ionic] [ 4371.404805] ionic_txrx_deinit+0x71/0x190 [ionic] [ 4371.404956] ionic_reconfigure_queues+0x5f5/0xff0 [ionic] [ 4371.4051 11] ionic_set_ringparam+0x2e8/0x3e0 [ionic] [4371.405265] ethnl_set_rings+ 0x1f1/0x300 [ 4371.405418] ethnl_default_set_doit+0xbb/0x160 [ 4371.405571] genl_family_rcv_msg_doit+0xff/0x130 [...] encontré que ionic_tx_clean() llama a napi_consume_skb() que llama a napi_skb_cache_put() , pero antes de esa última llamada está la nota /* El presupuesto cero indica que nos llamó un contexto que no es NAPI, como netpoll */ y DEBUG_NET_WARN_ON_ONCE(!in_softirq()); Esos son indicios bastante importantes de que lo estamos haciendo mal. Podemos pasar una sugerencia de contexto a través de las llamadas para que ionic_tx_clean() sepa lo que estamos haciendo para que pueda llamar a napi_consume_skb() correctamente.