Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: mmci: stm32: corregir la advertencia de asignaciones superpuestas de la API DMA Al activar CONFIG_DMA_API_DEBUG_SG se genera la siguiente advertencia: DMA-API: mmci-pl18x 48220000.mmc: seguimiento de línea de caché EEXIST, asignaciones superpuestas no son compatibles ADVERTENCIA: CPU: 1 PID: 51 en kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Módulos vinculados en: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 # 1 Nombre del hardware: STMicroelectronics STM32MP257F-EV1 Placa de evaluación (DT) Cola de trabajo: events_freezable mmc_rescan Rastreo de llamadas: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x1 0/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x 14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card +0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 La depuración de la API de DMA saca a la luz asignaciones de dma con fugas, ya que dma_map_sg y dma_unmap_sg no están correctamente equilibrados. Si se produce un error en la función mmci_cmd_irq, solo se llama a la función mmci_dma_error y como esta API no se administra en la variante stm32, nunca se llama a dma_unmap_sg en esta ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: fsl-qdma: init irq after reg inicialización Inicialice qDMA irqs después de configurar los registros para que las interrupciones que puedan haber estado pendientes de un kernel primario no sean procesadas por el controlador irq antes de que esté listo y cause pánico con el siguiente rastreo: Rastreo de llamadas: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x 178 generic_handle_irq+0x24/0x38 __handle_domain_irq +0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/ 0xe8 fsl_qdma_probe+0x4d4/0xca8 plataforma_drv_probe+0x50/0xa0 very_probe+0xe0/0x3f8 driver_probe_device +0x64/0x130 dispositivo_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x 44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable +0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: arm64/neonbs: corrige el acceso fuera de los límites en entradas cortas. La implementación de bits de AES-CTR opera en bloques de 128 bytes y recurrirá al Versión NEON simple para bloques finales o entradas que, para empezar, tienen menos de 128 bytes. Llamará directamente al asistente simple NEON asm, que realiza todos los accesos a la memoria en gránulos de 16 bytes (el tamaño de un registro NEON). Por esta razón, el código de pegamento NEON simple asociado copiará las entradas de menos de 16 bytes en un búfer temporal, dado que esto es algo poco común y no vale la pena el esfuerzo de solucionarlo en el código ASM. El respaldo de la versión NEON dividida en bits no tiene esto en cuenta, lo que podría provocar accesos fuera de los límites. Así que clone la misma solución y use un búfer temporal para entradas/salidas cortas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: fsl-qdma: corrección El SoC puede bloquearse en lecturas no alineadas de 16 bytes. Hay erratas en el chip (ls1028a): El SoC puede bloquearse en transacciones de lectura no alineadas de 16 bytes mediante QDMA. Las transacciones de lectura no alineadas iniciadas por QDMA pueden detenerse en el NOC (Network On-Chip), provocando una condición de interbloqueo. Las transacciones detenidas activarán tiempos de espera de finalización en el controlador PCIe. Solución alternativa: habilite la captación previa estableciendo el bit de captación previa del descriptor de origen ( SD[PF] = 1 ). Implemente esta solución.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: dev-replace: validar correctamente los nombres de los dispositivos. Hay un informe de syzbot que indica que los búferes de nombres de dispositivos pasados para reemplazar el dispositivo no se verifican adecuadamente para determinar la terminación de la cadena, lo que podría provocar una lectura fuera de los límites. en getname_kernel(). Agregue un asistente que valide los búferes de nombres de dispositivos de origen y de destino. Para devid como fuente, inicialice el búfer en una cadena vacía en caso de que algo intente leerlo más tarde. Esto fue originalmente analizado y solucionado de una manera diferente por Edward Adam Davis (ver enlaces).

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la doble liberación de un dispositivo anónimo después de un error en la creación de la instantánea. Al crear una instantánea podemos hacer una doble liberación de un dispositivo anónimo en caso de que haya un error al realizar la transacción. La segunda liberación puede resultar en la liberación de un número de dispositivo anónimo asignado por algún otro subSYSTEM en el kernel u otro SYSTEM de archivos btrfs. Los pasos que conducen a esto: 1) En ioctl.c:create_snapshot() asignamos un número de dispositivo anónimo y lo asignamos a pendiente_snapshot->anon_dev; 2) Luego llamamos a btrfs_commit_transaction() y terminamos en transaction.c:create_pending_snapshot(); 3) Allí llamamos a btrfs_get_new_fs_root() y le pasamos el número de dispositivo anónimo almacenado en pendiente_snapshot->anon_dev; 4) btrfs_get_new_fs_root() libera ese número de dispositivo anónimo porque btrfs_lookup_fs_root() devolvió una raíz; alguien más ya hizo una búsqueda de la nueva raíz, lo que podría realizar alguna tarea haciendo retroceder la referencia; 5) Después de eso, ocurre algún error en la ruta de confirmación de la transacción, y en ioctl.c:create_snapshot() saltamos a la etiqueta 'fail', y luego liberamos nuevamente el mismo número de dispositivo anónimo, que mientras tanto puede haber sido reasignado en otro lugar, porque pendiente_snapshot->anon_dev todavía tiene el mismo valor que en el paso 1. Recientemente, syzbot se encontró con esto e informó el siguiente seguimiento: ------------[ cortar aquí ]---- -------- ida_free solicitó id=51 que no está asignado. ADVERTENCIA: CPU: 1 PID: 31038 en lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525 Módulos vinculados en: CPU: 1 PID: 31038 Comm: syz-executor.2 No contaminado 6.8.0 -rc4-syzkaller-00410-gc02197fc9076 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525 Código: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 00000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 R SI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: ffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS :0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Rastreo de llamadas: < TAREA> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfs_ transacción_commit+0xf1c/ 0x3740 fs/btrfs/transaction.c:2404 create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs /ioctl.c :1044 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfs_ioctl+0xa74/0xd40 vfs_ioct l fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl .c:871 [en línea] __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Código: 28 00 00 00 ( ...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009 417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 00000000000000000 R10: 00000000000000000 R11: 00000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 Donde recibimos un mensaje explícito donde intentamos liberar un número de dispositivo anónimo que no está asignado actualmente.,---truncado---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: gtp: corrige use-after-free y null-ptr-deref en gtp_newlink() La estructura de operaciones gtp_link_ops para el subSYSTEM debe registrarse después de registrar la estructura de operaciones pernet gtp_net_ops. Syzkaller encontró el error 'fallo de protección general en gtp_genl_dump_pdp': [1010.702740] gtp: módulo GTP descargado [1010.715877] fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [1010.715888 ] KASAN: ptr nulo -deref en el rango [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out No contaminado 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Nombre de hardware: Estándar QEMU PC (Q35+ ICH9, 2009), BIOS 1.16.0-alt1 01/04/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Código: 80 3c 02 00 0f 85 41 04 00 0 0 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 4 8b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000 000 [ 1010.715933] RDX: 00000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 000000000000 0001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 00000000000 00000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555 554 [1010.715972] Seguimiento de llamadas: [1010.715985]? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [1010.716002]? exc_general_protection+0x199/0x2f0 [1010.716016]? asm_exc_general_protection+0x1e/0x30 [1010.716026]? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [1010.716063]? is_bpf_text_address+0xc0/0x1f0 [1010.716070]? kernel_text_address.part.0+0xbb/0xd0 [1010.716076]? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [1010.716091]? create_prof_cpu_mask+0x30/0x30 [1010.716098]? arch_stack_walk+0x9e/0xf0 [1010.716106]? stack_trace_save+0x91/0xd0 [1010.716113]? stack_trace_consume_entry+0x170/0x170 [1010.716121]? __lock_acquire+0x15c5/0x5380 [1010.716139]? mark_held_locks+0x9e/0xe0 [1010.716148]? ¿kmem_cache_alloc_trace+0x35f/0x3c0 [1010.716155]? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [1010.716179]? lock_acquire+0x1fe/0x560 [1010.716188]? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [1010.716208]? netlink_ack+0xab0/0xab0 [1010.716213]? netlink_deliver_tap+0x202/0xd50 [1010.716220]? netlink_deliver_tap+0x218/0xd50 [1010.716226]? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [1010.716248]? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [1010.716269]? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [1010.716304]? __ia32_sys_recvmmsg+0x270/0x270 [1010.716309]? lock_acquire+0x1fe/0x560 [1010.716315]? Drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [1010.716337]? lockdep_init_map ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la ejecución entre la finalización de extensión ordenada y fiemap Para fiemap recientemente dejamos de bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, para evitar un punto muerto en un escenario donde el búfer fiemap resulta ser un rango mapeado en memoria del mismo archivo. Es muy poco probable que este caso de uso sea útil en la práctica, pero puede activarse mediante pruebas difusas (syzbot, etc.). Sin embargo, al no bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, podemos competir con una extensión ordenada. Esto sucede así: 1) La tarea fiemap termina de procesar un elemento de extensión de archivo que cubre el rango de archivos [512K, 1M[, y ese elemento de extensión de archivo es el último elemento de la hoja que se está procesando actualmente; 2) Y la extensión ordenada para el rango de archivos [768K, 2M[, en modo COW, se completa (btrfs_finish_one_ordered()) y el elemento de extensión de archivo que cubre el rango [512K, 1M[ se recorta para cubrir el rango [512K, 768K[ y luego se inserta un nuevo elemento de extensión de archivo para el rango [768K, 2M[ en el árbol de subvolumen del inodo; 3) La tarea fiemap llama a fiemap_next_leaf_item(), que luego llama a btrfs_next_leaf() para encontrar la siguiente hoja/elemento. Esto encuentra que la siguiente clave después de la que procesamos anteriormente (su tipo es BTRFS_EXTENT_DATA_KEY y su desplazamiento es 512K), es la clave correspondiente al nuevo elemento de extensión de archivo insertado por la extensión ordenada, que tiene un tipo de BTRFS_EXTENT_DATA_KEY y un desplazamiento de 768K; 4) Más tarde, el código fiemap termina en emit_fiemap_extent() y activa la advertencia: if (cache->offset + cache->len > offset) { WARN_ON(1); devolver -EINVAL; } Dado que obtenemos 1M > 768K, porque la entrada emitida previamente para la extensión anterior que cubre el rango de archivos [512K, 1M[ termina en un desplazamiento que es mayor que el desplazamiento inicial de la nueva extensión (768K). Esto hace que fiemap falle con -EINVAL además de activar la advertencia que produce un seguimiento de pila como el siguiente: [1621.677651] ------------[ cortar aquí ]----------- - [1621.677656] ADVERTENCIA: CPU: 1 PID: 204366 en fs/btrfs/extent_io.c:2492 emit_fiemap_extent+0x84/0x90 [btrfs] [1621.677899] Módulos vinculados en: btrfs blake2b_generic (...) [1621.677951] CPU: 1 PID: 204366 Comm: pool No contaminado 6.8.0-rc5-btrfs-next-151+ #1 [1621.677954] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390- prebuilt.qemu.org 01/04/2014 [1621.677956] RIP: 0010:emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678033] Código: 2b 4c 89 63 (...) [1621.678035] RSP: 0018:ffffab160 89ffd20 EFLAGS: 00010206 [1621.678037] RAX: 00000000004fa000 RBX: ffffab16089ffe08 RCX: 0000000000009000 [1621.678039] RDX: 00000000004f9000 RSI: 00000000004f1000 RDI : ffffab16089ffe90 [1621.678040] RBP: 00000000004f9000 R08: 0000000000001000 R09: 00000000000000000 [1621.678041] R10: 0000000000000000 R11 : 0000000000001000 R12: 0000000041d78000 [1621.678043 ] R13: 0000000000001000 R14: 00000000000000000 R15: ffff9434f0b17850 [1621.678044] FS: 00007fa6e20006c0(0000) GS:ffff943bdfa40000(0000) kn lGS:0000000000000000 [1621.678046] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1621.678048] CR2: 00007fa6b0801000 CR3 : 000000012d404002 CR4: 0000000000370ef0 [1621.678053] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 [1621.678055] DR 3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1621.678056] Seguimiento de llamadas: [1621.678074] [1621.678076] ? __advertir+0x80/0x130 [1621.678082] ? emit_fiemap_extent+0x84/0x90 [btrfs] [1621.678159] ? report_bug+0x1f4/0x200 [1621.678164] ? ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: Sparse-Memory/vmemmap fuera de los límites corrige Offset vmemmap para que la primera página de vmemmap se asigne a la primera página de la memoria física para garantizar que vmemmap Los límites se respetarán durante las operaciones pfn_to_page()/page_to_pfn(). Las macros de conversión producirán direcciones SV39/48/57 correctas para cada DRAM_BASE posible/válida dentro de los límites de la memoria física. v2: Abordar los comentarios de Alex

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: perf: ctr_get_width la función para legado no está definida Con los parámetros CONFIG_RISCV_PMU_LEGACY=y y CONFIG_RISCV_PMU_SBI=n el kernel de Linux falla cuando intenta el registro de rendimiento: $ perf record ls [ 46.749286] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 [ 46.750199] Ups [#1] [ 46.750342] Módulos vinculados en: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Nombre del hardware : riscv-virtio,qemu (DT) [ 46.751184] epc : 0x0 [ 46.751430 ] ra : arch_perf_update_userpage+0x54/0x13e [ 46.751680] epc : 00000000000000000 ra : ffffffff8072ee52 sp : ff20000 00022b8f0 [46.751958] gp: ffffffff81505988 tp: ff6000000290d400 t0: ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a 1: ff600000028fb000 [46.752673] a2: 0000000ae2751268 a3: 00000000004fb708 a4: 00000000000000004 [46.752895] a5: 0000000000000000 a6: 000000000017ffe3 a7: 00000000000000d2 [46.753117] s2: ff600000028fb000 s3: 0000000ae2751268 s4: 0000000000000000 [46.753338] s5: ffffffff8153e290 s6: ff600000863b9000 s7: ff60000002 961078 [46.753562] s8: ff60000002961048 s9: ff60000002961058 s10: 00000000000000001 [46.753783] s11: 0000000000000018 t3: ffffffffffffff ff t4 : ffffffffffffffff [ 46.754005] t5 : ff6000000292270c t6: ff2000000022bb30 [46.754179] estado: 0000000200000100 badaddr: 00000000000000000 causa: 0000000000000000c [46.754653] Código: No se puede acceder instrucción en 0xffffffffffffffec. [ 46.754939] ---[ end trace 0000000000000000 ]--- [ 46.755131] nota: perf-exec[107] salió con irqs deshabilitados [ 46.755546] nota: perf-exec[107] salió con preempt_count 4 Esto sucede porque en el legado En este caso, la función ctr_get_width no se definió, pero se usa en arch_perf_update_userpage. También elimine el control adicional en riscv_pmu_ctr_get_width_mask

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Previene un posible desbordamiento del búfer en map_hw_resources Agrega una verificación en la función map_hw_resources para evitar un posible desbordamiento del búfer. La función accedía a matrices utilizando un índice que potencialmente podría ser mayor que el tamaño de las matrices, lo que provocaba un desbordamiento del búfer. Agrega una verificación para garantizar que el índice esté dentro de los límites de las matrices. Si el índice está fuera de los límites, se imprime un mensaje de error y, al interrumpirlo, continuará la ejecución ignorando los datos adicionales antes de tiempo para evitar el desbordamiento del búfer. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 error map_hw_resources(): desbordamiento del búfer 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id' 6 <= 7 controladores/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:81 error map_hw_resources(): desbordamiento del búfer 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id' 6 <= 7

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: corrige el puntero no inicializado dmactl. En el caso de que se llame a __lpass_get_dmactl_handle y el ID del controlador dai_id no sea válido, al puntero dmactl no se le asigna un valor y dmactl contiene un valor basura. ya que no se ha inicializado y, por lo tanto, es posible que la verificación nula no funcione. Solucione esto para inicializar dmactl a NULL. Se podría argumentar que los compiladores modernos establecerán esto en cero, pero es útil mantenerlo inicializado de la misma manera en las funciones __lpass_platform_codec_intf_init y lpass_cdc_dma_daiops_hw_params. Limpia la advertencia de compilación de escaneo clang: sound/soc/qcom/lpass-cdc-dma.c:275:7: advertencia: la condición de rama se evalúa como un valor basura [core.uninitialized.Branch]