Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommufd: corrige la actualización faltante de domains_itree después de dividir iopt_area. En iopt_area_split(), si el iopt_area original ha llenado un dominio y está vinculado a domains_itree, los pages_nodes deben reinsertarse correctamente. De lo contrario, domains_itree se corrompe y usaremos UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: stm32-adc: endurece contra puntero NULL deref en stm32_adc_probe() of_match_device() puede fallar y devuelve un puntero NULL. En la práctica, no se conoce una forma razonable de activar esto, pero en caso de que se agregue una en el futuro, endurezca el código agregando la verificación

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: el cliente RPC limpió los pipefs dentries liberados. La limpieza de pipefs dentries del cliente RPC está en la cola de trabajo separada rpc_remove_pipedir(), que se encarga del bloqueo del superbloque de pipefs. En algunos escenarios especiales, cuando el kernel libera el pipefs sb del cliente actual e inmediatamente asigna un nuevo pipefs sb, la función rpc_remove_pipedir juzgaría mal la existencia de pipefs sb que no es el que solía contener. Como resultado, rpc_remove_pipedir limpiaría las dentrías de pipefs liberadas. Para solucionar este problema, rpc_remove_pipedir debe verificar si el pipefs sb actual es consistente con el pipefs sb original. KASAN puede detectar este error: ============================================ =============== [250.497700] BUG: KASAN: slab-use-after-free en dget_parent+0x195/0x200 [250.498315] Lectura de tamaño 4 en la dirección ffff88800a2ab804 por tarea kworker/0 :18/106503 [250.500549] Cola de trabajo: eventos rpc_free_client_work [250.501001] Seguimiento de llamadas: [250.502880] kasan_report+0xb6/0xf0 [250.503209]? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] /0x230 [ 250.505598] Process_one_work+0x8ee/0x13b0 ... [ 22.039056] Asignado por la tarea 244: [ 22.039390 ] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.0408 89] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive +0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057 ] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ... [ 22.049524] Liberado por la tarea 0: [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] 25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Última creación de trabajo potencialmente relacionado: [ 22.052952] kasan_save_stack+0x22/ 0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ __dentry_kill+ 0x3be/0x540 [22.054900] Shrink_dentry_list+0x199/0x510 [22.055293] Shrink_dcache_parent+ 0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] 3a/0x60 [22.057234] rpc_kill_sb+0x121/0x200

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/jfs: agregue verificación de validez para db_maxag y db_agpref. Tanto db_maxag como db_agpref se utilizan como índice de la matriz db_agfree, pero actualmente no hay verificación de validez para db_maxag y db_agpref, lo cual puede dar lugar a errores. El siguiente es un error relacionado reportado por Syzbot: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20 el índice 7936 está fuera de rango para el tipo 'atomic_t[128]' Agregue verificando que el Los valores de db_maxag y db_agpref son índices válidos para la matriz db_agfree.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: corrige el índice de matriz fuera de los límites en diAlloc. Actualmente no se verifica el agno del iag al asignar nuevos inodos para evitar problemas de fragmentación. Se agregó la comprobación que se requiere.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ALSA: hda: Corrige posible null-ptr-deref al asignar un flujo. Si bien los controladores AudioDSP asignan flujos exclusivamente de tipo HOST o LINK, nada impide que un usuario intente asignar un flujo ACOPLADO. Como la instancia de subsecuencia proporcionada puede ser un código auxiliar, cuál es el caso cuando se carga el código, dicho escenario termina con null-ptr-deref.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: config: soluciona el problema de iteración en 'usb_get_bos_descriptor()'. El descriptor BOS define un descriptor raíz y es el descriptor base para acceder a una familia de descriptores relacionados. La función 'usb_get_bos_descriptor()' encuentra un problema de iteración al omitir el tipo de descriptor 'USB_DT_DEVICE_CAPABILITY'. Esto da como resultado que el mismo descriptor se lea repetidamente. Para solucionar este problema, se introduce una declaración 'goto' para garantizar que el puntero y la cantidad leída se actualicen correctamente. Esto garantiza que la función pase al siguiente descriptor en lugar de leer el mismo descriptor repetidamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: realice un seguimiento del envío de xmit a PTP WQ después de completar el mapa de metadatos. Asegúrese de que el skb esté disponible en el mapeo de metadatos a skbs antes de realizar un seguimiento del índice de metadatos para detectar CQE no entregados. Si el índice de metadatos se coloca en la lista de seguimiento antes de colocar el skb en el mapa, el índice de metadatos podría usarse para detectar CQE no entregados antes de que el skb relevante esté disponible en el mapa, lo que puede generar un null-ptr-deref. Registro: falla de protección general, probablemente para dirección no canónica 0xdffffc0000000005: 0000 [#1] SMP KASAN KASAN: null-ptr-deref en rango [0x0000000000000028-0x0000000000000002f] CPU: 0 PID: 1243 Comm: kworker/0:2 Not tain ted 6.6.0-rc4+ #108 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Cola de trabajo: eventos mlx5e_rx_dim_work [mlx5_core] RIP : 0010:mlx5e_ptp_napi_poll+0x9a4/0x2290 [mlx5_core] Código: 8c 24 38 cc ff ff 4c 8d 3c c1 4c 89 f9 48 c1 e9 03 42 80 3c 31 00 0f 85 97 0f 00 00 4d 8b 3f 49 8d 7f 28 48 89 f9 48 c1 e9 03 <42> 80 3c 31 00 0f 85 8b 0f 00 00 49 8b 47 28 48 85 c0 0f 84 05 07 RSP: 0018:ffff8884d3c09c88 EFLAGS: 00010206 RAX: 000000000069 RBX: ffff8881160349d8 RCX: 0000000000000005 RDX: ffffed10218f48cf RSI : 0000000000000004 RDI: 0000000000000028 RBP: ffff888122707700 R08: 0000000000000001 R09: ffffed109a781383 R10: 0000000000000003 R11: 00000000000003 R12: ffff88810c7a7a40 R13: ffff888122707700 R14: dffffc0000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff888 4d3c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f878dd6e0 CR3: 000000014d108002 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000 000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 Seguimiento de llamadas: ? die_addr+0x3c/0xa0? exc_general_protection+0x144/0x210? asm_exc_general_protection+0x22/0x30? mlx5e_ptp_napi_poll+0x9a4/0x2290 [mlx5_core] ? mlx5e_ptp_napi_poll+0x8f6/0x2290 [mlx5_core] __napi_poll.constprop.0+0xa4/0x580 net_rx_action+0x460/0xb80 ? _raw_spin_unlock_irqrestore+0x32/0x60? __napi_poll.constprop.0+0x580/0x580? tasklet_action_common.isra.0+0x2ef/0x760 __do_softirq+0x26c/0x827 irq_exit_rcu+0xc2/0x100 common_interrupt+0x7f/0xa0 asm_common_interrupt+0x22/0x40 RIP 0010:__kmem_cache_alloc_node+ 0xb/0x330 Código: 41 5d 41 5e 41 5f c3 8b 44 24 14 8b 4c 24 10 09 c8 eb d5 e8 b7 43 ca 01 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 <41> 56 41 89 41 55 41 89 f5 41 54 49 89 fc 53 48 83 e4 f0 48 83 RSP: 0018:ffff88812c4079c0 EFLAGS: 00000246 RAX: 1ffffffff083c7fe RBX: ffff888100042dc0 RCX: 218 RDX: 00000000ffffffff RSI: 0000000000000dc0 RDI: ffff888100042dc0 RBP: ffff88812c4079c8 R08: ffffffffa0289f96 R09: ffffed1025880ea9 R10: ffff888138839f80 R11: 00000000000000002 R12: 0000000000000dc0 R13: 0000000000000100 R14: 0000000000000008c R15: ffff8881271fc450 ? cmd_exec+0x796/0x2200 [mlx5_core] kmalloc_trace+0x26/0xc0 cmd_exec+0x796/0x2200 [mlx5_core] mlx5_cmd_do+0x22/0xc0 [mlx5_core] mlx5_cmd_exec+0x17/0x30 [mlx5_core] modificar_cq_moderation+0x139/0x1b0 [mlx5_core] ? mlx5_add_cq_to_tasklet+0x280/0x280 [mlx5_core] ? lockdep_set_lock_cmp_fn+0x190/0x190? Process_one_work+0x659/0x1220 mlx5e_rx_dim_work+0x9d/0x100 [mlx5_core] Process_one_work+0x730/0x1220 ? lockdep_hardirqs_on_prepare+0x400/0x400? max_active_store+0xf0/0xf0? assign_work+0x168/0x240 worker_thread+0x70f/0x12d0? __kthread_parkme+0xd1/0x1d0 ? process_one_work+0x1220/0x1220 kthread+0x2d9/0x3b0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x2d/0x70 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_as ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wangxun: corrige el pánico del kernel debido a un puntero null. Cuando el dispositivo utiliza un ID de proveedor de subsistema personalizado, la función wx_sw_init() regresa antes de que se agote la memoria de 'wx->mac_table'. asignado. El puntero null provocará el pánico en el kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: detener el dispositivo en bond_setup_by_slave(). El compromiso 9eed321cde22 ("net: lapbether: solo admite dispositivos ethernet") ha podido mantener a syzbot alejado de net/lapb, hasta hoy. En el siguiente símbolo [1], el problema es que se ha creado un dispositivo lapbether sobre un dispositivo de unión sin miembros. Luego, agregar un miembro que no sea ARPHRD_ETHER obligó al maestro de vinculación a cambiar su tipo. La solución es asegurarnos de llamar a dev_close() en bond_setup_by_slave() para que se eliminen los posibles dispositivos lapbether vinculados (o cualquier otro dispositivo que tenga suposiciones sobre el dispositivo físico). Se solucionó un error similar en la confirmación 40baec225765 ("vinculación: corregir el pánico en caso de falla de esclavitud no ARPHRD_ETHER") [1] skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end: 0x140 dev:bond0 ERROR del kernel en net/core/skbuff.c:192! Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 6007 Comm: syz-executor383 No contaminado 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Nombre de hardware: Google Google Compute Engine/ Google Compute Engine, BIOS Google 04/08/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: skb_panic net/core/skbuff.c:188 [en línea] pc: skb_under_panic +0x13c/0x140 net/core/skbuff.c:202 lr: skb_panic net/core/skbuff.c:188 [en línea] lr: skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 sp: ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 0000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008 a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 000000000000000 x9: cb50b496c519aa00 x8: cb50b496c519aa00 x7: 0000000000000001 x6: 00000000000001 x5: ffff800096a063b8 x4: ffff80008e280f80 x3: ffff8000805ad11c x2: 0000000000000001 x1: 0000000100000201 x0: 00000000000000 086 Rastreo de llamadas: skb_panic net/core/skbuff.c:188 [en línea] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/ netdevice.h:3136 [en línea] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c :149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0 núcleo x1a4/0x510 /notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [en línea] call_netdevice_notifiers_extack net/core/dev.c:2008 [en línea] call_netdevice_notifiers net/core/dev .c:2022 [en línea] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event +0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [ en línea] call_netdevice_notifiers_extack net/core/dev.c:2008 [en línea] call_netdevice_notifiers net/core/dev.c:2022 [en línea] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core /dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c :4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: soluciona el problema de ejecuciones entre ufshcd_mcq_abort() e ISR. Si se agota el tiempo de espera del comando y se genera cq complete IRQ al mismo tiempo, ufshcd_mcq_abort borra lprb->cmd y un La eliminación del puntero NULL ocurre en el ISR. Registro de errores: ufshcd_abort: tarea de cancelación del dispositivo en la etiqueta 18 No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000108 pc: [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44 lr: [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24 /0x114

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrige la verificación de datos en línea de racy may en dio write syzbot informa que la siguiente advertencia de ext4_iomap_begin() se activa a partir de la confirmación a la que se hace referencia a continuación: if (WARN_ON_ONCE(ext4_has_inline_data(inode)) ) devolver -ERANGE; Esto ocurre durante una escritura dio, que nunca se espera que encuentre un inodo con datos en línea. Para imponer este comportamiento, ext4_dio_write_iter() verifica el estado en línea actual del inodo y borra el indicador de estado MAY_INLINE_DATA para volver a las escrituras almacenadas en el búfer o imponer que otros escritores en progreso en el inodo no puedan crear datos en línea. El problema es que la verificación de datos en línea existentes y la bandera de estado puede abarcar un ciclo de bloqueo. Por ejemplo, si el ilock originalmente estaba bloqueado como compartido y posteriormente actualizado a exclusivo, es posible que otro escritor haya vuelto a adquirir el bloqueo y haya creado datos en línea antes de que la tarea de escritura dio adquiera el bloqueo y continúe. El compromiso al que se hace referencia a continuación afloja los requisitos de bloqueo para permitir que se produzcan algunas formas de escrituras de dio no alineadas bajo un bloqueo compartido, pero AFAICT, la verificación de datos en línea técnicamente ya era picante para cualquier escritura de dio que hubiera involucrado un ciclo de bloqueo. De todos modos, limpie el bit de estado en la misma sección crítica de bloqueo que verifica si hay datos en línea preexistentes en el inodo para cerrar la ejecución.