Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> flex_proportions: hacer que fprop_new_period() sea seguro para hardirq<br /> <br /> Bernd ha reportado un lockdep splat del código de proporciones flexibles que esencialmente se queja de la siguiente condición de carrera:<br /> <br /> <br /> run_timer_softirq - estamos en contexto de softirq<br /> call_timer_fn<br /> writeout_period<br /> fprop_new_period<br /> write_seqcount_begin(&amp;amp;p-&amp;gt;sequence);<br /> <br /> <br /> ...<br /> blk_mq_end_request()<br /> blk_update_request()<br /> ext4_end_bio()<br /> folio_end_writeback()<br /> __wb_writeout_add()<br /> __fprop_add_percpu_max()<br /> if (unlikely(max_frac &amp;lt; FPROP_FRAC_BASE)) {<br /> fprop_fraction_percpu()<br /> seq = read_seqcount_begin(&amp;amp;p-&amp;gt;sequence);<br /> - ve una secuencia impar por lo que entra en un bucle indefinido<br /> <br /> Tenga en cuenta que un interbloqueo como este solo es posible si el bdi ha configurado una fracción máxima de rendimiento de escritura, lo cual es muy raro en general pero frecuente, por ejemplo, para bdis FUSE. Para solucionar este problema, tenemos que asegurarnos de que la sección de escritura del contador de secuencia sea irqsafe.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5e: TC, eliminar flujos solo para pares existentes<br /> <br /> Al eliminar flujos de direccionamiento TC, iterar solo sobre pares devcom reales en lugar de asumir que todos los puertos posibles existen. Esto evita tocar pares no existentes y asegura que la limpieza se limite a los dispositivos a los que el controlador está conectado actualmente.<br /> <br /> ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008<br /> #PF: acceso de escritura de supervisor en modo kernel<br /> #PF: error_code(0x0002) - página no presente<br /> PGD 133c8a067 P4D 0<br /> Oops: Oops: 0002 [#1] SMP<br /> CPU: 19 UID: 0 PID: 2169 Comm: tc No contaminado 6.18.0+ #156 NINGUNO<br /> Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core]<br /> Código: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff &amp;lt;48&amp;gt; 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49<br /> RSP: 0018:ff11000143867528 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000<br /> RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0<br /> RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002<br /> R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78<br /> R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0<br /> FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0<br /> Traza de Llamada:<br /> <br /> mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]<br /> mlx5e_flow_put+0x25/0x50 [mlx5_core]<br /> mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]<br /> tc_setup_cb_reoffload+0x20/0x80<br /> fl_reoffload+0x26f/0x2f0 [cls_flower]<br /> ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]<br /> ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]<br /> tcf_block_playback_offloads+0

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mptcp: corrección de condición de carrera en mptcp_pm_nl_flush_addrs_doit()<br /> <br /> syzbot y Eulgyu Kim reportaron fallos en mptcp_pm_nl_get_local_id() y/o mptcp_pm_nl_is_backup()<br /> <br /> La causa raíz es list_splice_init() en mptcp_pm_nl_flush_addrs_doit() que no está preparada para RCU.<br /> <br /> list_splice_init_rcu() no puede ser llamada aquí mientras se mantiene el spinlock pernet-&amp;gt;lock.<br /> <br /> Muchas gracias a Eulgyu Kim por proporcionar una reproducción y probar nuestros parches.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bonding: corrige el uso después de liberación debido a un fallo de enslave después de la actualización del array de esclavos<br /> <br /> Corrige un uso después de liberación que ocurre debido a un fallo de enslave después de que el nuevo esclavo ha sido añadido al array. Dado que el nuevo esclavo puede ser usado para Tx inmediatamente, podemos usarlo después de que ha sido liberado por la ruta de limpieza de errores de enslave que libera la memoria del esclavo asignada. Se supone que la actualización del array de esclavos debe ser llamada al final cuando no se esperan más fallos de enslave. Muévelo después de la configuración de xdp para evitar cualquier problema.<br /> <br /> Es muy fácil reproducir el problema con un programa xdp_pass simple:<br /> ip l add bond1 type bond mode balance-xor<br /> ip l set bond1 up<br /> ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass<br /> ip l add dumdum type dummy<br /> <br /> Luego ejecuta en paralelo:<br /> while :; do ip l set dumdum master bond1 1&amp;gt;/dev/null 2&amp;gt;&amp;amp;1; done;<br /> mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp &amp;#39;dp=1-1023, flags=syn&amp;#39;<br /> <br /> El fallo ocurre casi inmediatamente:<br /> [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI<br /> [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]<br /> [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary)<br /> [ 605.602979] Tainted: [B]=BAD_PAGE<br /> [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210<br /> [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 &amp;lt;80&amp;gt; 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89<br /> [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213<br /> [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000<br /> [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be<br /> [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c<br /> [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000<br /> [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84<br /> [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000<br /> [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0<br /> [ 605.603373] Call Trace:<br /> [ 605.603392] <br /> [ 605.603410] __dev_queue_xmit+0x448/0x32a0<br /> [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10<br /> [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10<br /> [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10<br /> [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603546] ? _printk+0xcb/0x100<br /> [ 605.603566] ? __pfx__printk+0x10/0x10<br /> [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603627] ? add_taint+0x5e/0x70<br /> [ 605.603648] ? add_taint+0x2a/0x70<br /> [ 605.603670] ? end_report.cold+0x51/0x75<br /> [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: wwan: t7xx: corrige un potencial desbordamiento de skb-&amp;gt;frags en la ruta RX<br /> <br /> Al recibir datos en la ruta RX de DPMAIF, la función t7xx_dpmaif_set_frag_to_skb() añade fragmentos de página a un skb sin comprobar si el número de fragmentos ha excedido MAX_SKB_FRAGS. Esto podría conducir a un desbordamiento de búfer en el array skb_shinfo(skb)-&amp;gt;frags[], corrompiendo memoria adyacente y potencialmente causando fallos del kernel u otro comportamiento indefinido.<br /> <br /> Este problema fue identificado a través de análisis de código estático comparando con una vulnerabilidad similar corregida en el commit b102f0c522cf del controlador mt76 (&amp;#39;mt76: corrige el desbordamiento del array al recibir demasiados fragmentos para un paquete&amp;#39;).<br /> <br /> La vulnerabilidad podría ser activada si el firmware del módem envía paquetes con fragmentos excesivos. Si bien bajo condiciones normales del protocolo (MTU 3080 bytes, búfer BAT 3584 bytes), un solo paquete no debería requerir fragmentos adicionales, el kernel no debería confiar ciegamente en el comportamiento del firmware. Firmware malicioso, con errores o comprometido podría potencialmente crear paquetes con más fragmentos de los que el kernel espera.<br /> <br /> Solucione esto añadiendo una comprobación de límites antes de llamar a skb_add_rx_frag() para asegurar que nr_frags no exceda MAX_SKB_FRAGS.<br /> <br /> La comprobación debe realizarse antes de desmapear para evitar una fuga de página y un doble desmapeo DMA durante el desmontaje del dispositivo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: nfc: nci: Solucionar condición de carrera entre rfkill y nci_unregister_device(). syzbot informó del &amp;#39;splat&amp;#39; a continuación [0] sin una reproducción. Indica que la estructura nci_dev.cmd_wq había sido destruida antes de que se llamara a nci_close_device() a través de rfkill. nci_dev.cmd_wq solo se destruye en nci_unregister_device(), que (creo) fue llamada desde virtual_ncidev_close() cuando syzbot cerró un &amp;#39;fd&amp;#39; de virtual_ncidev. El problema es que nci_unregister_device() destruye nci_dev.cmd_wq primero y luego llama a nfc_unregister_device(), que elimina el dispositivo de rfkill mediante rfkill_unregister(). Así, el dispositivo sigue siendo visible a través de rfkill incluso después de que nci_dev.cmd_wq sea destruida. Desregistremos el dispositivo de rfkill primero en nci_unregister_device(). Tenga en cuenta que no podemos llamar a nfc_unregister_device() antes de nci_close_device() porque 1) nfc_unregister_device() llama a device_del() que libera toda la memoria asignada por devm_kzalloc() y vinculada a ndev-&amp;gt;conn_info_list 2) nci_rx_work() podría intentar encolar nci_conn_info a ndev-&amp;gt;conn_info_list lo que podría provocar una fuga de memoria Por lo tanto, nfc_unregister_device() se divide en dos funciones para que podamos eliminar las interfaces de rfkill solo antes de nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) ADVERTENCIA: kernel/locking/lockdep.c:238 en hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 ADVERTENCIA: kernel/locking/lockdep.c:238 en check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 ADVERTENCIA: kernel/locking/lockdep.c:238 en __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Módulos enlazados: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 No contaminado syzkaller #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Código: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d &amp;lt;67&amp;gt; 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Ruta de llamada: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: Corrige la desreferencia de puntero NULL en ice_vsi_set_napi_queues<br /> <br /> Añade comprobaciones de puntero NULL en ice_vsi_set_napi_queues() para evitar fallos durante la reanudación desde la suspensión cuando rings[q_idx]-&amp;gt;q_vector es NULL.<br /> <br /> Adaptador probado:<br /> 60:00.0 Controlador Ethernet [0200]: Intel Corporation Ethernet Controller E810-XXV para SFP [8086:159b] (rev 02)<br /> Subsistema: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]<br /> <br /> Estado de SR-IOV: tanto deshabilitado como habilitado pueden reproducir este problema.<br /> <br /> versión del kernel: v6.18<br /> <br /> Pasos para reproducir:<br /> Arrancar y ejecutar la suspensión como systemctl suspend o rtcwake.<br /> <br /> Registro:<br /> &amp;lt;1&amp;gt;[ 231.443607] BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000040<br /> &amp;lt;1&amp;gt;[ 231.444052] #PF: acceso de lectura de supervisor en modo kernel<br /> &amp;lt;1&amp;gt;[ 231.444484] #PF: código_de_error(0x0000) - página no presente<br /> &amp;lt;6&amp;gt;[ 231.444913] PGD 0 P4D 0<br /> &amp;lt;4&amp;gt;[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI<br /> &amp;lt;4&amp;gt;[ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170<br /> &amp;lt;4&amp;gt;[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b &amp;lt;48&amp;gt; 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89<br /> &amp;lt;4&amp;gt;[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202<br /> &amp;lt;4&amp;gt;[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010<br /> &amp;lt;4&amp;gt;[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000<br /> &amp;lt;4&amp;gt;[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000<br /> &amp;lt;4&amp;gt;[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<br /> &amp;lt;4&amp;gt;[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000<br /> &amp;lt;4&amp;gt;[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000<br /> &amp;lt;4&amp;gt;[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> &amp;lt;4&amp;gt;[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0<br /> &amp;lt;4&amp;gt;[ 231.451629] PKRU: 55555554<br /> &amp;lt;4&amp;gt;[ 231.452076] Traza de llamada:<br /> &amp;lt;4&amp;gt;[ 231.452549] <br /> &amp;lt;4&amp;gt;[ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice]<br /> &amp;lt;4&amp;gt;[ 231.453482] ice_resume+0xfd/0x220 [ice]<br /> &amp;lt;4&amp;gt;[ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10<br /> &amp;lt;4&amp;gt;[ 231.454425] pci_pm_resume+0x8c/0x140<br /> &amp;lt;4&amp;gt;[ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10<br /> &amp;lt;4&amp;gt;[ 231.455347] dpm_run_callback+0x5f/0x160<br /> &amp;lt;4&amp;gt;[ 231.455796] ? dpm_wait_for_superior+0x107/0x170<br /> &amp;lt;4&amp;gt;[ 231.456244] device_resume+0x177/0x270<br /> &amp;lt;4&amp;gt;[ 231.456708] dpm_resume+0x209/0x2f0<br /> &amp;lt;4&amp;gt;[ 231.457151] dpm_resume_end+0x15/0x30<br /> &amp;lt;4&amp;gt;[ 231.457596] suspend_devices_and_enter+0x1da/0x2b0<br /> &amp;lt;4&amp;gt;[ 231.458054] enter_state+0x10e/0x570<br /> <br /> Añade comprobaciones defensivas tanto para el puntero del anillo como para su q_vector antes de desreferenciar, permitiendo que el sistema se reanude con éxito incluso cuando los q_vectors no están mapeados.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> sfc: soluciona interbloqueo en la lectura de configuración RSS<br /> <br /> Desde el commit citado, el núcleo bloquea el rss_lock del net_device al manejar el comando ethtool -x, por lo que la implementación del controlador no debería bloquearlo de nuevo. Eliminar esto último.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rocker: corregir fuga de memoria en rocker_world_port_post_fini()<br /> <br /> En rocker_world_port_pre_init(), rocker_port-&amp;gt;wpriv se asigna con kzalloc(wops-&amp;gt;port_priv_size, GFP_KERNEL). Sin embargo, en rocker_world_port_post_fini(), la memoria solo se libera cuando la devolución de llamada wops-&amp;gt;port_post_fini está establecida:<br /> <br /> si (!wops-&amp;gt;port_post_fini)<br /> retornar;<br /> wops-&amp;gt;port_post_fini(rocker_port);<br /> kfree(rocker_port-&amp;gt;wpriv);<br /> <br /> Dado que rocker_ofdpa_ops no implementa la devolución de llamada port_post_fini (es NULL), la memoria wpriv asignada para cada puerto nunca se libera cuando se eliminan los puertos. Esto conduce a una fuga de memoria de sizeof(struct ofdpa_port) bytes por puerto en cada eliminación de dispositivo.<br /> <br /> Solucione esto llamando siempre a kfree(rocker_port-&amp;gt;wpriv) independientemente de si existe la devolución de llamada port_post_fini.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdgpu: corrige la desreferenciación de puntero NULL en amdgpu_gmc_filter_faults_remove<br /> <br /> En APUs como Raven y Renoir (GC 9.1.0, 9.2.2, 9.3.0), los búferes de anillo de interrupción ih1 e ih2 no están inicializados. Esto es intencional, ya que estos anillos IH secundarios solo están disponibles en GPUs discretas. Véase vega10_ih_sw_init() que explícitamente omite la inicialización de ih1/ih2 cuando AMD_IS_APU está configurado.<br /> <br /> Sin embargo, amdgpu_gmc_filter_faults_remove() usa incondicionalmente ih1 para obtener la marca de tiempo de la última entrada de interrupción. Cuando las fallas de reintento están habilitadas en APUs (noretry=0), esta función es llamada desde la ruta de recuperación de fallas de página SVM, lo que resulta en una desreferenciación de puntero NULL cuando amdgpu_ih_decode_iv_ts_helper() intenta acceder a ih-&amp;gt;ring[].<br /> <br /> El fallo se manifiesta como:<br /> <br /> BUG: desreferenciación de puntero NULL del kernel, dirección: 0000000000000004<br /> RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]<br /> Call Trace:<br /> amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]<br /> svm_range_restore_pages+0xae5/0x11c0 [amdgpu]<br /> amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]<br /> gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]<br /> amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]<br /> amdgpu_ih_process+0x84/0x100 [amdgpu]<br /> <br /> Este problema fue expuesto por el commit 1446226d32a4 (&amp;#39;drm/amdgpu: Eliminar GC HW IP 9.3.0 de noretry=1&amp;#39;) que cambió el valor predeterminado para la APU Renoir de noretry=1 a noretry=0, habilitando el manejo de fallas de reintento y, por lo tanto, ejercitando la ruta de código defectuosa.<br /> <br /> Solucione esto añadiendo una comprobación para ih1.ring_size antes de intentar usarlo. También restaure el soporte soft_ih del commit dd299441654f (&amp;#39;drm/amdgpu: Reestructurar la eliminación de fallas de reintento&amp;#39;). Esto es necesario si el hardware no soporta anillos IH de hardware secundarios.<br /> <br /> v2: actualizaciones adicionales (Alex)<br /> <br /> (seleccionado de commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/xe/nvm: Corrige doble liberación en fallo de adición de aux<br /> <br /> Después de una exitosa auxiliary_device_init(), aux_dev-&amp;gt;dev.release (xe_nvm_release_dev()) es responsable de la kfree(nvm). Cuando hay un fallo con auxiliary_device_add(), el controlador llamará a auxiliary_device_uninit(), que llama a put_device(). De modo que la devolución de llamada .release se activará para liberar la memoria asociada con el auxiliary_device.<br /> <br /> Mueve la kfree(nvm) a la ruta de fallo de auxiliary_device_init() y elimina la ruta err goto para corregir el error a continuación.<br /> <br /> [ 13.232905] ==================================================================<br /> [ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe]<br /> [ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273<br /> <br /> [ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary)<br /> ...<br /> [ 13.233125] Call Trace:<br /> [ 13.233126] <br /> [ 13.233127] dump_stack_lvl+0x7f/0xc0<br /> [ 13.233132] print_report+0xce/0x610<br /> [ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0<br /> [ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe]<br /> ...<br /> <br /> v2: elimina la ruta err goto. (Alexander)<br /> <br /> (seleccionado de la confirmación a3187c0c2bbd947ffff97f90d077ac88f9c2a215)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> octeon_ep: Corrección de fuga de memoria en octep_device_setup()<br /> <br /> En octep_device_setup(), si octep_ctrl_net_init() falla, la función retorna directamente sin desmapear los recursos mapeados y liberar la memoria de configuración asignada.<br /> <br /> Esto se corrige saltando a la etiqueta unsupported_dev, la cual realiza la limpieza necesaria. Esto se alinea con la lógica de manejo de errores de otras rutas en esta función.<br /> <br /> Probado únicamente en compilación. Problema encontrado usando una herramienta prototipo de análisis estático y revisión de código.