Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> powerpc/pseries: Reestructurar lppaca_shared_proc() para evitar DEBUG_PREEMPT<br /> <br /> lppaca_shared_proc() toma un puntero al lppaca al que se accede típicamente a través de get_lppaca(). Con DEBUG_PREEMPT habilitado, esto lleva a verificar si la preemptibilidad está habilitada, por ejemplo:<br /> <br /> BUG: usando smp_processor_id() en código preemptible [00000000]: grep/10693<br /> el llamador es lparcfg_data+0x408/0x19a0<br /> CPU: 4 PID: 10693 Comm: grep No contaminado 6.5.0-rc3 #2<br /> Traza de Llamadas:<br /> dump_stack_lvl+0x154/0x200 (no fiable)<br /> check_preemption_disabled+0x214/0x220<br /> lparcfg_data+0x408/0x19a0<br /> ...<br /> <br /> Esto no es realmente un problema, sin embargo, ya que no importa qué lppaca se acceda, el estado compartido del proceso será el mismo. vcpudispatch_stats_procfs_init() ya soluciona esto deshabilitando la preemptibilidad, pero el código lparcfg no lo hace, generando un error cada vez que se accede a /proc/powerpc/lparcfg con DEBUG_PREEMPT habilitado.<br /> <br /> En lugar de deshabilitar la preemptibilidad en el lado del llamador, reestructurar lppaca_shared_proc() para que no tome un puntero y en su lugar acceda directamente al lppaca, evitando cualquier posible verificación de preemptibilidad.<br /> <br /> [mpe: Reestructurar para evitar la necesidad de una definición en paca.h y lppaca.h]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> debugobjects: No despertar a kswapd desde fill_pool()<br /> <br /> syzbot está reportando una advertencia de lockdep en fill_pool() porque la asignación de debugobjects está usando GFP_ATOMIC, que es (__GFP_HIGH | __GFP_KSWAPD_RECLAIM) y por lo tanto intenta despertar a kswapd, que adquiere kswapd_wait::lock.<br /> <br /> Dado que fill_pool() podría ser llamado con bloqueos arbitrarios mantenidos, fill_pool() no debería asumir que adquirir kswapd_wait::lock es seguro.<br /> <br /> Usar __GFP_HIGH en su lugar y eliminar __GFP_NORETRY ya que es inútil para la asignación !__GFP_DIRECT_RECLAIM.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> SUNRPC: doble liberación de xprt_ctxt mientras aún está en uso<br /> <br /> Cuando una solicitud RPC es diferida, el puntero rq_xprt_ctxt es movido fuera del svc_rqst hacia el svc_deferred_req.<br /> Cuando la solicitud diferida es revisitada, el puntero es copiado en el nuevo svc_rqst - y también permanece en el svc_deferred_req.<br /> <br /> En el caso (¿raro?) de que la solicitud sea diferida por segunda vez, el antiguo svc_deferred_req es reutilizado - aún tiene todo el contenido correcto.<br /> Sin embargo, en ese caso el puntero rq_xprt_ctxt NO es limpiado de modo que cuando se llama a xpo_release_xprt, el ctxt es liberado (UDP) o posiblemente añadido a una lista de libres (RDMA).<br /> Cuando la solicitud diferida es revisitada por segunda vez, hará referencia a este ctxt el cual puede ser inválido, y liberará el objeto por segunda vez lo que probablemente causará un &amp;#39;oops&amp;#39;.<br /> <br /> Así que cambie svc_defer() para *siempre* limpiar rq_xprt_ctxt, y afirme que el valor ahora está almacenado en el svc_deferred_req.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: usb: siano: Soluciona errores de uso después de liberación causados por do_submit_urb<br /> <br /> Hay errores UAF causados por do_submit_urb(). Uno de los informes de KASan se muestra a continuación:<br /> <br /> [ 36.403605] BUG: KASAN: use-after-free in worker_thread+0x4a2/0x890<br /> [ 36.406105] Read of size 8 at addr ffff8880059600e8 by task kworker/0:2/49<br /> [ 36.408316]<br /> [ 36.408867] CPU: 0 PID: 49 Comm: kworker/0:2 Not tainted 6.2.0-rc3-15798-g5a41237ad1d4-dir8<br /> [ 36.411696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584<br /> [ 36.416157] Workqueue: 0x0 (events)<br /> [ 36.417654] Call Trace:<br /> [ 36.418546] <br /> [ 36.419320] dump_stack_lvl+0x96/0xd0<br /> [ 36.420522] print_address_description+0x75/0x350<br /> [ 36.421992] print_report+0x11b/0x250<br /> [ 36.423174] ? _raw_spin_lock_irqsave+0x87/0xd0<br /> [ 36.424806] ? __virt_addr_valid+0xcf/0x170<br /> [ 36.426069] ? worker_thread+0x4a2/0x890<br /> [ 36.427355] kasan_report+0x131/0x160<br /> [ 36.428556] ? worker_thread+0x4a2/0x890<br /> [ 36.430053] worker_thread+0x4a2/0x890<br /> [ 36.431297] ? worker_clr_flags+0x90/0x90<br /> [ 36.432479] kthread+0x166/0x190<br /> [ 36.433493] ? kthread_blkcg+0x50/0x50<br /> [ 36.434669] ret_from_fork+0x22/0x30<br /> [ 36.435923] <br /> [ 36.436684]<br /> [ 36.437215] Allocated by task 24:<br /> [ 36.438289] kasan_set_track+0x50/0x80<br /> [ 36.439436] __kasan_kmalloc+0x89/0xa0<br /> [ 36.440566] smsusb_probe+0x374/0xc90<br /> [ 36.441920] usb_probe_interface+0x2d1/0x4c0<br /> [ 36.443253] really_probe+0x1d5/0x580<br /> [ 36.444539] __driver_probe_device+0xe3/0x130<br /> [ 36.446085] driver_probe_device+0x49/0x220<br /> [ 36.447423] __device_attach_driver+0x19e/0x1b0<br /> [ 36.448931] bus_for_each_drv+0xcb/0x110<br /> [ 36.450217] __device_attach+0x132/0x1f0<br /> [ 36.451470] bus_probe_device+0x59/0xf0<br /> [ 36.452563] device_add+0x4ec/0x7b0<br /> [ 36.453830] usb_set_configuration+0xc63/0xe10<br /> [ 36.455230] usb_generic_driver_probe+0x3b/0x80<br /> [ 36.456166] printk: console [ttyGS0] disabled<br /> [ 36.456569] usb_probe_device+0x90/0x110<br /> [ 36.459523] really_probe+0x1d5/0x580<br /> [ 36.461027] __driver_probe_device+0xe3/0x130<br /> [ 36.462465] driver_probe_device+0x49/0x220<br /> [ 36.463847] __device_attach_driver+0x19e/0x1b0<br /> [ 36.465229] bus_for_each_drv+0xcb/0x110<br /> [ 36.466466] __device_attach+0x132/0x1f0<br /> [ 36.467799] bus_probe_device+0x59/0xf0<br /> [ 36.469010] device_add+0x4ec/0x7b0<br /> [ 36.470125] usb_new_device+0x863/0xa00<br /> [ 36.471374] hub_event+0x18c7/0x2220<br /> [ 36.472746] process_one_work+0x34c/0x5b0<br /> [ 36.474041] worker_thread+0x4b7/0x890<br /> [ 36.475216] kthread+0x166/0x190<br /> [ 36.476267] ret_from_fork+0x22/0x30<br /> [ 36.477447]<br /> [ 36.478160] Freed by task 24:<br /> [ 36.479239] kasan_set_track+0x50/0x80<br /> [ 36.480512] kasan_save_free_info+0x2b/0x40<br /> [ 36.481808] ____kasan_slab_free+0x122/0x1a0<br /> [ 36.483173] __kmem_cache_free+0xc4/0x200<br /> [ 36.484563] smsusb_term_device+0xcd/0xf0<br /> [ 36.485896] smsusb_probe+0xc85/0xc90<br /> [ 36.486976] usb_probe_interface+0x2d1/0x4c0<br /> [ 36.488303] really_probe+0x1d5/0x580<br /> [ 36.489498] __driver_probe_device+0xe3/0x130<br /> [ 36.491140] driver_probe_device+0x49/0x220<br /> [ 36.492475] __device_attach_driver+0x19e/0x1b0<br /> [ 36.493988] bus_for_each_drv+0xcb/0x110<br /> [ 36.495171] __device_attach+0x132/0x1f0<br /> [ 36.496617] bus_probe_device+0x59/0xf0<br /> [ 36.497875] device_add+0x4ec/0x7b0<br /> [ 36.498972] usb_set_configuration+0xc63/0xe10<br /> [ 36.500264] usb_generic_driver_probe+0x3b/0x80<br /> [ 36.501740] usb_probe_device+0x90/0x110<br /> [ 36.503084] really_probe+0x1d5/0x580<br /> [ 36.504241] __driver_probe_device+0xe3/0x130<br /> [ 36.505548] driver_probe_device+0x49/0x220<br /> [ 36.506766] __device_attach_driver+0x19e/0x1b0<br /> [ 36.508368] bus_for_each_drv+0xcb/0x110<br /> [ 36.509646] __device_attach+0x132/0x1f0<br /> [ 36.510911] bus_probe_device+0x59/0xf0<br /> [ 36.512103] device_add+0x4ec/0x7b0<br /> [ 36.513215] usb_new_device+0x863/0xa00<br /> [ 36.514736] hub_event+0x18c7/0x2220<br /> [ 36.516130] process_one_work+<br /> ---truncated---

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

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/ttm: No filtrar un recurso en error de desalojo<br /> <br /> En errores de desalojo distintos de -EMULTIHOP, se estaba filtrando un recurso.<br /> Solución.<br /> <br /> v2:<br /> - Evitar otro &amp;#39;goto&amp;#39; más (Andi Shyti)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> sh: dma: Corrección del cálculo del desplazamiento del canal DMA<br /> <br /> Varios SoCs de la familia SH3, SH4 y SH4A, que utilizan este controlador, presentan un número diferente de canales DMA, que pueden distribuirse entre hasta dos módulos DMAC. La implementación existente no logra adaptarse correctamente a todas esas variaciones, lo que resulta en cálculos de desplazamiento de canal incorrectos y conduce a pánicos del kernel.<br /> <br /> Reescribir dma_base_addr() para calcular correctamente los desplazamientos de canal en un módulo DMAC. Corregir dmaor_read_reg() y dmaor_write_reg(), para que se seleccione la base correcta del módulo DMAC para el registro DMAOR.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: fix a memory corruption in extended buffer descriptor mode<br /> <br /> For quite some time we were chasing a bug which looked like a sudden<br /> permanent failure of networking and mmc on some of our devices.<br /> The bug was very sensitive to any software changes and even more to<br /> any kernel debug options.<br /> <br /> Finally we got a setup where the problem was reproducible with<br /> CONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:<br /> <br /> [ 16.992082] ------------[ cut here ]------------<br /> [ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes]<br /> [ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900<br /> [ 17.018977] Modules linked in: xxxxx<br /> [ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28<br /> [ 17.045345] Hardware name: xxxxx<br /> [ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)<br /> [ 17.054322] pc : check_unmap+0x6a0/0x900<br /> [ 17.058243] lr : check_unmap+0x6a0/0x900<br /> [ 17.062163] sp : ffffffc010003c40<br /> [ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c<br /> [ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800<br /> [ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8<br /> [ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750<br /> [ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000<br /> [ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010<br /> [ 17.097343] x17: 0000000000000000 x16: 0000000000000000<br /> [ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720<br /> [ 17.107959] x13: 0720072007200720 x12: 0720072007200720<br /> [ 17.113261] x11: 0720072007200720 x10: 0720072007200720<br /> [ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d<br /> [ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098<br /> [ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000<br /> [ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370<br /> [ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000<br /> [ 17.145082] Call trace:<br /> [ 17.147524] check_unmap+0x6a0/0x900<br /> [ 17.151091] debug_dma_unmap_page+0x88/0x90<br /> [ 17.155266] gem_rx+0x114/0x2f0<br /> [ 17.158396] macb_poll+0x58/0x100<br /> [ 17.161705] net_rx_action+0x118/0x400<br /> [ 17.165445] __do_softirq+0x138/0x36c<br /> [ 17.169100] irq_exit+0x98/0xc0<br /> [ 17.172234] __handle_domain_irq+0x64/0xc0<br /> [ 17.176320] gic_handle_irq+0x5c/0xc0<br /> [ 17.179974] el1_irq+0xb8/0x140<br /> [ 17.183109] xiic_process+0x5c/0xe30<br /> [ 17.186677] irq_thread_fn+0x28/0x90<br /> [ 17.190244] irq_thread+0x208/0x2a0<br /> [ 17.193724] kthread+0x130/0x140<br /> [ 17.196945] ret_from_fork+0x10/0x20<br /> [ 17.200510] ---[ end trace 7240980785f81d6f ]---<br /> <br /> [ 237.021490] ------------[ cut here ]------------<br /> [ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b<br /> [ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240<br /> [ 237.041802] Modules linked in: xxxxx<br /> [ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28<br /> [ 237.068941] Hardware name: xxxxx<br /> [ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)<br /> [ 237.077900] pc : add_dma_entry+0x214/0x240<br /> [ 237.081986] lr : add_dma_entry+0x214/0x240<br /> [ 237.086072] sp : ffffffc010003c30<br /> [ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00<br /> [ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0<br /> [ 237.099987] x25: 0000000000000002 x24: 0000000000000000<br /> [ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00<br /> [ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600<br /> [ 237.115897] x19: 00000000ffffffef x18: 0000000000000010<br /> [ 237.121201] x17: 0000000000000000 x16: 0000000000000000<br /> [ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720<br /> [ 237.131807] x13: 0720072007200720 x12: 0720072007200720<br /> [ 237.137111] x11: 0720072007200720 x10: 0720072007200720<br /> [ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259<br /> [ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000<br /> [ 237.15302<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cifs: corrige un posible oops en cifs_oplock_break<br /> <br /> Con el cierre diferido podemos tener cierres que compiten con las interrupciones de arrendamiento, y así, con las comprobaciones actuales para determinar si enviar la respuesta de arrendamiento, oplock_response(), esto puede significar que un desmontaje (kill_sb) puede ocurrir justo antes de que estuviéramos comprobando si tcon-&amp;gt;ses es válido. Véase a continuación:<br /> <br /> [Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs]<br /> [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e &amp;lt;48&amp;gt; 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39<br /> [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206<br /> [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009<br /> [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188<br /> [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900<br /> [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138<br /> [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000<br /> [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000<br /> [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0<br /> [Fri Aug 4 04:12:50 2023] Call Trace:<br /> [Fri Aug 4 04:12:50 2023] <br /> [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0<br /> [Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0<br /> [Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0<br /> [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150<br /> [Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50<br /> [Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30<br /> [Fri Aug 4 04:12:50 2023] <br /> <br /> Para solucionar esto, cambie el orden de las comprobaciones antes de enviar la oplock_response para comprobar primero si la openFileList está vacía.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> soundwire: bus: Corrige pm_runtime_put() desequilibrado que causa un subdesbordamiento del contador de uso<br /> <br /> Esto revierte el commit<br /> 443a98e649b4 (&amp;#39;soundwire: bus: usa pm_runtime_resume_and_get()&amp;#39;)<br /> <br /> Cambia las llamadas a pm_runtime_resume_and_get() de vuelta a pm_runtime_get_sync(). Esto corrige un subdesbordamiento del contador de uso causado por realizar un pm_runtime_put() incluso si pm_runtime_resume_and_get() devolvió un error.<br /> <br /> Las tres funciones afectadas ignoran el error -EACCES al intentar obtener pm_runtime, y continúan, incluyendo un put al final de la función. Pero pm_runtime_resume_and_get() no incrementa el contador de uso si devuelve un error. Así que en el caso de -EACCES no se debe llamar a pm_runtime_put().<br /> <br /> La documentación de pm_runtime_get_sync() dice:<br /> &amp;#39;Considere usar pm_runtime_resume_and_get() ... ya que esto probablemente resultará en un código más limpio.&amp;#39;<br /> <br /> En este caso no creo que resulte en un código más limpio porque el pm_runtime_put() al final de la función tendría que ser condicional al valor de retorno de pm_runtime_resume_and_get() al principio de la función.<br /> <br /> pm_runtime_get_sync() no tiene este problema porque siempre incrementa el contador, por lo que siempre necesita un put. El código puede simplemente fluir y realizar el pm_runtime_put() incondicionalmente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cifs: Corrección: pérdida de la destrucción de la conexión smbd cuando la asignación de MR falló<br /> <br /> Si la asignación de MR falló, la información de conexión directa smb es NULL,<br /> entonces smbd_destroy() regresará directamente, entonces la información de conexión<br /> se filtrará.<br /> <br /> Establezcamos la información de conexión directa smb al servidor antes de llamar a smbd_destroy().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdkfd: Añadir los callbacks faltantes del gestor MQD de gfx11<br /> <br /> La función mqd_stride fue introducida en el commit 2f77b9a242a2<br /> (&amp;#39;drm/amdkfd: Actualizar la gestión de MQD en una configuración multi-XCC&amp;#39;)<br /> pero no asignada para gfx11. Corrige una desreferencia NULL en debugfs.