Vulnerabilidades

Un archivo RGB creado maliciosamente, al ser analizado por Autodesk 3ds Max, puede forzar una vulnerabilidad de corrupción de memoria. Un actor malicioso puede aprovechar esta vulnerabilidad para ejecutar código arbitrario en el contexto del proceso actual.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver<br /> <br /> at91_adc_interrupt can call at91_adc_touch_data_handler function<br /> to start the work by schedule_work(&amp;st-&gt;touch_st.workq).<br /> <br /> If we remove the module which will call at91_adc_remove to<br /> make cleanup, it will free indio_dev through iio_device_unregister but<br /> quite a bit later. While the work mentioned above will be used. The<br /> sequence of operations that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | at91_adc_workq_handler<br /> at91_adc_remove |<br /> iio_device_unregister(indio_dev) |<br /> //free indio_dev a bit later |<br /> | iio_push_to_buffers(indio_dev)<br /> | //use indio_dev<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in at91_adc_remove.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> phy: qcom-qusb2: Corrección de desreferencia de puntero NULL en suspensión temprana<br /> <br /> Habilitar PM en tiempo de ejecución antes de adjuntar la instancia QPHY como datos del controlador puede llevar a una desreferencia de puntero NULL en las retrollamadas de PM en tiempo de ejecución que esperan datos de controlador válidos. Hay una pequeña ventana donde la retrollamada de suspensión puede ejecutarse después de la habilitación de PM en tiempo de ejecución y antes de la prohibición en tiempo de ejecución. Esto causa un fallo esporádico durante el arranque:<br /> <br /> ```<br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1<br /> [...]<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPT<br /> Workqueue: pm pm_runtime_work<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2]<br /> lr : pm_generic_runtime_suspend+0x2c/0x44<br /> [...]<br /> ```<br /> <br /> Adjuntar la instancia QPHY como datos del controlador antes de habilitar PM en tiempo de ejecución para prevenir la desreferencia de puntero NULL en las retrollamadas de PM en tiempo de ejecución.<br /> <br /> Reordenar pm_runtime_enable() y pm_runtime_forbid() para prevenir una ventana corta donde puede ocurrir una suspensión en tiempo de ejecución innecesaria.<br /> <br /> Usar la versión gestionada por devres para asegurar que PM en tiempo de ejecución se deshabilite simétricamente durante la eliminación del controlador para una limpieza adecuada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> w1: therm: Corrección de desbordamiento de búfer por un byte en alarms_store<br /> <br /> El búfer sysfs pasado a alarms_store() se asigna con &amp;#39;size + 1&amp;#39; bytes y se añade un terminador NUL. Sin embargo, el argumento &amp;#39;size&amp;#39; no tiene en cuenta este byte adicional. El código original entonces asignaba &amp;#39;size&amp;#39; bytes y usaba strcpy() para copiar &amp;#39;buf&amp;#39;, lo que siempre escribe un byte más allá del búfer asignado ya que strcpy() copia hasta el terminador NUL en el índice &amp;#39;size&amp;#39;.<br /> <br /> Esto se soluciona analizando el parámetro &amp;#39;buf&amp;#39; directamente usando simple_strtoll() sin asignar ninguna memoria intermedia ni copiar cadenas. Esto elimina el desbordamiento mientras simplifica el código.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: corrige interbloqueo en wait_current_trans() debido a un tipo de transacción ignorado<br /> <br /> Cuando se llama a wait_current_trans() durante start_transaction(), actualmente espera por una transacción bloqueada sin considerar si el tipo de transacción dado realmente necesita esperar por ese estado de transacción particular. El array btrfs_blocked_trans_types[] ya define qué tipos de transacción deben esperar por qué estados de transacción, pero esta verificación faltaba en wait_current_trans().<br /> <br /> Esto puede llevar a un escenario de interbloqueo que involucra dos transacciones y extensiones ordenadas pendientes:<br /> <br /> 1. La Transacción A está en estado TRANS_STATE_COMMIT_DOING<br /> 2. Un worker que procesa una extensión ordenada llama a start_transaction() con TRANS_JOIN<br /> 3. join_transaction() devuelve -EBUSY porque la Transacción A está en TRANS_STATE_COMMIT_DOING<br /> 4. La Transacción A pasa a TRANS_STATE_UNBLOCKED y se completa<br /> 5. Se crea una nueva Transacción B (TRANS_STATE_RUNNING)<br /> 6. La extensión ordenada del paso 2 se añade a las extensiones ordenadas pendientes de la Transacción B<br /> 7. La Transacción B inicia inmediatamente la confirmación por otra tarea y entra en TRANS_STATE_COMMIT_START<br /> 8. El worker finalmente llega a wait_current_trans(), ve la Transacción B en TRANS_STATE_COMMIT_START (un estado bloqueado), y espera incondicionalmente<br /> 9. Sin embargo, TRANS_JOIN NO debería esperar por TRANS_STATE_COMMIT_START según btrfs_blocked_trans_types[]<br /> 10. La Transacción B está esperando que las extensiones ordenadas pendientes se completen<br /> 11. Interbloqueo: La Transacción B espera por la extensión ordenada, la extensión ordenada espera por la Transacción B<br /> <br /> Esto puede ilustrarse con las siguientes pilas de llamadas:<br /> CPU0 CPU1<br /> btrfs_finish_ordered_io()<br /> start_transaction(TRANS_JOIN)<br /> join_transaction()<br /> # -EBUSY (La Transacción A está en<br /> # TRANS_STATE_COMMIT_DOING)<br /> # La Transacción A se completa<br /> # La Transacción B creada<br /> # extensión ordenada añadida a<br /> # la lista pendiente de la Transacción B<br /> btrfs_commit_transaction()<br /> # La Transacción B entra en<br /> # TRANS_STATE_COMMIT_START<br /> # esperando por extensiones ordenadas<br /> # pendientes<br /> wait_current_trans()<br /> # espera por la Transacción B<br /> # (¡no debería esperar!)<br /> <br /> Tarea bstore_kv_sync en btrfs_commit_transaction esperando por extensiones ordenadas:<br /> <br /> __schedule+0x2e7/0x8a0<br /> schedule+0x64/0xe0<br /> btrfs_commit_transaction+0xbf7/0xda0 [btrfs]<br /> btrfs_sync_file+0x342/0x4d0 [btrfs]<br /> __x64_sys_fdatasync+0x4b/0x80<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Tarea kworker en wait_current_trans esperando por la confirmación de la transacción:<br /> <br /> Cola de trabajo: btrfs-syno_nocow btrfs_work_helper [btrfs]<br /> __schedule+0x2e7/0x8a0<br /> schedule+0x64/0xe0<br /> wait_current_trans+0xb0/0x110 [btrfs]<br /> start_transaction+0x346/0x5b0 [btrfs]<br /> btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]<br /> btrfs_work_helper+0xe8/0x350 [btrfs]<br /> process_one_work+0x1d3/0x3c0<br /> worker_thread+0x4d/0x3e0<br /> kthread+0x12d/0x150<br /> ret_from_fork+0x1f/0x30<br /> <br /> Solucione esto pasando el tipo de transacción a wait_current_trans() y verificando btrfs_blocked_trans_types[cur_trans-&amp;gt;state] contra el tipo dado antes de decidir esperar. Esto asegura que los tipos de transacción a los que se les permite unirse durante ciertos estados bloqueados no esperarán innecesariamente y causarán interbloqueos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: xilinx: xdma: Corrección de regmap max_register<br /> <br /> Al campo max_register se le asigna el tamaño de la región de memoria del registro en lugar del desplazamiento del último registro.<br /> El resultado es que la lectura del regmap a través de debugfs puede causar un fallo de segmentación:<br /> <br /> tail /sys/kernel/debug/regmap/xdma.1.auto/registers<br /> No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff800082f70000<br /> Información de aborto de memoria:<br /> ESR = 0x0000000096000007<br /> EC = 0x25: DABT (EL actual), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x07: fallo de traducción de nivel 3<br /> [...]<br /> Rastreo de llamadas:<br /> regmap_mmio_read32le+0x10/0x30<br /> _regmap_bus_reg_read+0x74/0xc0<br /> _regmap_read+0x68/0x198<br /> regmap_read+0x54/0x88<br /> regmap_read_debugfs+0x140/0x380<br /> regmap_map_read_file+0x30/0x48<br /> full_proxy_read+0x68/0xc8<br /> vfs_read+0xcc/0x310<br /> ksys_read+0x7c/0x120<br /> __arm64_sys_read+0x24/0x40<br /> invoke_syscall.constprop.0+0x64/0x108<br /> do_el0_svc+0xb0/0xd8<br /> el0_svc+0x38/0x130<br /> el0t_64_sync_handler+0x120/0x138<br /> el0t_64_sync+0x194/0x198<br /> Código: aa1e03e9 d503201f f9400000 8b214000 (b9400000)<br /> ---[ fin del rastreo 0000000000000000 ]---<br /> nota: tail[1217] salió con las IRQ deshabilitadas<br /> nota: tail[1217] salió con preempt_count 1<br /> Fallo de segmentación

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> phy: stm32-usphyc: Corrección de un error &amp;#39;off by one&amp;#39; en probe()<br /> <br /> La variable &amp;#39;index&amp;#39; se utiliza como índice en el array usbphyc-&amp;gt;phys[] que tiene usbphyc-&amp;gt;nphys elementos. Así que si es igual a usbphyc-&amp;gt;nphys, entonces está un elemento fuera de los límites. El &amp;#39;index&amp;#39; proviene del árbol de dispositivos, por lo que son datos en los que confiamos y es poco probable que sea incorrecto; sin embargo, obviamente, aún vale la pena corregir el error. Cambiar el &amp;gt; por &amp;gt;=.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iio: imu: st_lsm6dsx: corregir iio_chan_spec para sensores sin detección de eventos<br /> <br /> El array st_lsm6dsx_acc_channels de la estructura iio_chan_spec tiene un campo event_spec no nulo, indicando soporte para eventos IIO. Sin embargo, la detección de eventos no es compatible con todos los sensores, y si el espacio de usuario intenta configurar eventos de activación del acelerómetro en un dispositivo sensor que no los soporta (p. ej., LSM6DS0), st_lsm6dsx_write_event() desreferencia un puntero NULL al intentar escribir en el registro de activación.<br /> Definir un array adicional de la estructura iio_chan_spec cuyos miembros tienen un campo event_spec NULL, y usar este array en lugar de st_lsm6dsx_acc_channels para sensores sin capacidad de detección de eventos.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Desde la versión 1.65.0 hasta antes de la 1.114.3, el uso de Buffer.allocUnsafe() y Buffer.allocUnsafeSlow() en el ejecutor de tareas permitió que código no confiable asignara memoria no inicializada. Dichos búferes no inicializados podrían contener datos residuales del mismo proceso de Node.js (por ejemplo, datos de solicitudes anteriores, tareas, secretos o tokens), lo que resultaría en una potencial revelación de información. Este problema ha sido parcheado en la versión 1.114.3.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/ena: corregir bloqueo faltante al actualizar los parámetros de devlink<br /> <br /> Corregir la advertencia de bloqueo de aserción al llamar a devl_param_driverinit_value_set() en ena.<br /> <br /> ADVERTENCIA: net/devlink/core.c:261 at devl_assert_locked+0x62/0x90, CPU#0: kworker/0:0/9<br /> CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 No contaminado 6.19.0-rc2+ #1 PREEMPT(lazy)<br /> Nombre del hardware: Amazon EC2 m8i-flex.4xlarge/, BIOS 1.0 10/16/2017<br /> Cola de trabajo: events work_for_cpu_fn<br /> RIP: 0010:devl_assert_locked+0x62/0x90<br /> <br /> Traza de llamada:<br /> <br /> devl_param_driverinit_value_set+0x15/0x1c0<br /> ena_devlink_alloc+0x18c/0x220 [ena]<br /> ? __pfx_ena_devlink_alloc+0x10/0x10 [ena]<br /> ? trace_hardirqs_on+0x18/0x140<br /> ? lockdep_hardirqs_on+0x8c/0x130<br /> ? __raw_spin_unlock_irqrestore+0x5d/0x80<br /> ? __raw_spin_unlock_irqrestore+0x46/0x80<br /> ? devm_ioremap_wc+0x9a/0xd0<br /> ena_probe+0x4d2/0x1b20 [ena]<br /> ? __lock_acquire+0x56a/0xbd0<br /> ? __pfx_ena_probe+0x10/0x10 [ena]<br /> ? local_clock+0x15/0x30<br /> ? __lock_release.isra.0+0x1c9/0x340<br /> ? mark_held_locks+0x40/0x70<br /> ? lockdep_hardirqs_on_prepare.part.0+0x92/0x170<br /> ? trace_hardirqs_on+0x18/0x140<br /> ? lockdep_hardirqs_on+0x8c/0x130<br /> ? __raw_spin_unlock_irqrestore+0x5d/0x80<br /> ? __raw_spin_unlock_irqrestore+0x46/0x80<br /> ? __pfx_ena_probe+0x10/0x10 [ena]<br /> ......<br />

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: hacer que calc_target() establezca t-&amp;gt;paused, no solo lo borre<br /> <br /> Actualmente, calc_target() borra t-&amp;gt;paused si la solicitud ya no debería estar en pausa, pero nunca establece t-&amp;gt;paused a pesar de que es capaz de determinar cuándo la solicitud debería estar en pausa. El establecimiento de t-&amp;gt;paused se deja a __submit_request(), lo cual está bien para las solicitudes regulares pero no funciona para las solicitudes persistentes (linger requests) -- ya que __submit_request() no opera en solicitudes persistentes, no hay dónde establecer lreq-&amp;gt;t.paused. Una consecuencia de esto es que las vigilancias no se restablecen en las transiciones de pausado -&amp;gt; despausado en casos donde las solicitudes han estado en pausa el tiempo suficiente para que la solicitud de desvigilancia (unwatch) (pausada) expire y para que la solicitud de (re)vigilancia (re)watch subsiguiente entre en el estado de pausa. Además de que la vigilancia no se restablece, rbd_reregister_watch() se queda atascado con rbd_dev-&amp;gt;watch_mutex retenido:<br /> <br /> rbd_register_watch<br /> __rbd_register_watch<br /> ceph_osdc_watch<br /> linger_reg_commit_wait<br /> <br /> Está esperando que lreq-&amp;gt;reg_commit_wait se complete, pero para que eso suceda la solicitud respectiva necesita terminar en la lista need_resend_linger y ser activada cuando las solicitudes se despausan. No hay posibilidad de eso si la solicitud en cuestión nunca se marca como pausada en primer lugar.<br /> <br /> El hecho de que rbd_dev-&amp;gt;watch_mutex permanezca retenido indefinidamente entonces evita que la imagen se desmapee -- &amp;#39;rbd unmap&amp;#39; se colgaría inevitablemente en estado D en un intento de tomar el mutex.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> virtio_net: corrige la falta de coincidencia de dispositivo en devm_kzalloc/devm_kfree<br /> <br /> La asignación inicial de rss_hdr utiliza virtio_device-&amp;gt;device,<br /> pero virtnet_set_queues() libera utilizando net_device-&amp;gt;device.<br /> Esta falta de coincidencia de dispositivo causa la siguiente advertencia de devres<br /> <br /> [ 3788.514041] ------------[ cut here ]------------<br /> [ 3788.514044] WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98, CPU#16: vdpa/1463<br /> [ 3788.514054] Modules linked in: octep_vdpa virtio_net virtio_vdpa [last unloaded: virtio_vdpa]<br /> [ 3788.514064] CPU: 16 UID: 0 PID: 1463 Comm: vdpa Tainted: G W 6.18.0 #10 PREEMPT<br /> [ 3788.514067] Tainted: [W]=WARN<br /> [ 3788.514069] Hardware name: Marvell CN106XX board (DT)<br /> [ 3788.514071] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> [ 3788.514074] pc : devm_kfree+0x84/0x98<br /> [ 3788.514076] lr : devm_kfree+0x54/0x98<br /> [ 3788.514079] sp : ffff800084e2f220<br /> [ 3788.514080] x29: ffff800084e2f220 x28: ffff0003b2366000 x27: 000000000000003f<br /> [ 3788.514085] x26: 000000000000003f x25: ffff000106f17c10 x24: 0000000000000080<br /> [ 3788.514089] x23: ffff00045bb8ab08 x22: ffff00045bb8a000 x21: 0000000000000018<br /> [ 3788.514093] x20: ffff0004355c3080 x19: ffff00045bb8aa00 x18: 0000000000080000<br /> [ 3788.514098] x17: 0000000000000040 x16: 000000000000001f x15: 000000000007ffff<br /> [ 3788.514102] x14: 0000000000000488 x13: 0000000000000005 x12: 00000000000fffff<br /> [ 3788.514106] x11: ffffffffffffffff x10: 0000000000000005 x9 : ffff800080c8c05c<br /> [ 3788.514110] x8 : ffff800084e2eeb8 x7 : 0000000000000000 x6 : 000000000000003f<br /> [ 3788.514115] x5 : ffff8000831bafe0 x4 : ffff800080c8b010 x3 : ffff0004355c3080<br /> [ 3788.514119] x2 : ffff0004355c3080 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 3788.514123] Call trace:<br /> [ 3788.514125] devm_kfree+0x84/0x98 (P)<br /> [ 3788.514129] virtnet_set_queues+0x134/0x2e8 [virtio_net]<br /> [ 3788.514135] virtnet_probe+0x9c0/0xe00 [virtio_net]<br /> [ 3788.514139] virtio_dev_probe+0x1e0/0x338<br /> [ 3788.514144] really_probe+0xc8/0x3a0<br /> [ 3788.514149] __driver_probe_device+0x84/0x170<br /> [ 3788.514152] driver_probe_device+0x44/0x120<br /> [ 3788.514155] __device_attach_driver+0xc4/0x168<br /> [ 3788.514158] bus_for_each_drv+0x8c/0xf0<br /> [ 3788.514161] __device_attach+0xa4/0x1c0<br /> [ 3788.514164] device_initial_probe+0x1c/0x30<br /> [ 3788.514168] bus_probe_device+0xb4/0xc0<br /> [ 3788.514170] device_add+0x614/0x828<br /> [ 3788.514173] register_virtio_device+0x214/0x258<br /> [ 3788.514175] virtio_vdpa_probe+0xa0/0x110 [virtio_vdpa]<br /> [ 3788.514179] vdpa_dev_probe+0xa8/0xd8<br /> [ 3788.514183] really_probe+0xc8/0x3a0<br /> [ 3788.514186] __driver_probe_device+0x84/0x170<br /> [ 3788.514189] driver_probe_device+0x44/0x120<br /> [ 3788.514192] __device_attach_driver+0xc4/0x168<br /> [ 3788.514195] bus_for_each_drv+0x8c/0xf0<br /> [ 3788.514197] __device_attach+0xa4/0x1c0<br /> [ 3788.514200] device_initial_probe+0x1c/0x30<br /> [ 3788.514203] bus_probe_device+0xb4/0xc0<br /> [ 3788.514206] device_add+0x614/0x828<br /> [ 3788.514209] _vdpa_register_device+0x58/0x88<br /> [ 3788.514211] octep_vdpa_dev_add+0x104/0x228 [octep_vdpa]<br /> [ 3788.514215] vdpa_nl_cmd_dev_add_set_doit+0x2d0/0x3c0<br /> [ 3788.514218] genl_family_rcv_msg_doit+0xe4/0x158<br /> [ 3788.514222] genl_rcv_msg+0x218/0x298<br /> [ 3788.514225] netlink_rcv_skb+0x64/0x138<br /> [ 3788.514229] genl_rcv+0x40/0x60<br /> [ 3788.514233] netlink_unicast+0x32c/0x3b0<br /> [ 3788.514237] netlink_sendmsg+0x170/0x3b8<br /> [ 3788.514241] __sys_sendto+0x12c/0x1c0<br /> [ 3788.514246] __arm64_sys_sendto+0x30/0x48<br /> [ 3788.514249] invoke_syscall.constprop.0+0x58/0xf8<br /> [ 3788.514255] do_el0_svc+0x48/0xd0<br /> [ 3788.514259] el0_svc+0x48/0x210<br /> [ 3788.514264] el0t_64_sync_handler+0xa0/0xe8<br /> [ 3788.514268] el0t_64_sync+0x198/0x1a0<br /> [ 3788.514271] ---[ end trace 0000000000000000 ]---<br /> <br /> Solución mediante el uso de virtio_device-&amp;gt;device de forma consistente para la asignación y desasignación