Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm: mxsfb: corrige el fallo de desreferencia del puntero NULL al descargar Es posible que mxsfb->crtc.funcs ya sea NULL al descargar el controlador, en cuyo caso se llama a mxsfb_irq_disable() a través de drm_irq_uninstall() desde mxsfb_unload() conduce a la desreferencia del puntero NULL. Dado que lo único que nos importa es enmascarar la IRQ y mxsfb->base sigue siendo válido, simplemente utilícelo para borrar y enmascarar la IRQ.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: mdiobus: corrige la pérdida de memoria en __mdiobus_register Una vez que falló device_register(), debemos llamar a put_device() para disminuir el recuento de referencias para la sanitización. O provocará una pérdida de memoria. Error: fuga de memoria objeto no referenciado 0xffff888114032e00 (tamaño 256): Comm "KWorker/1: 3", PID 2960, Jiffies 4294943572 (Edad 15.920) Volcado Hex (Primer 32 bytes): 00 00 00 00 00 00 00 08 2E 03333 14 81 88 y ff ................ 08 2e 03 14 81 88 y ff 90 76 65 82 y ff ff ff .........ve... .. backtrace: [] kmalloc include/linux/slab.h:591 [en línea] [] kzalloc include/linux/slab.h:721 [en línea] [] device_private_init drivers/base/ core.c:3203 [en línea] [] device_add+0x89b/0xdf0 drivers/base/core.c:3253 [] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537 [< ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87 [] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [en línea] [] 88772_bind+controladores 0x330/0x480 /net/usb/asix_devices.c:786 [] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c :396 [] call_driver_probe controladores/base/dd.c:517 [en línea] [] reality_probe.part.0+0xe7/0x380 controladores/base/dd.c:596 [] controladores very_probe /base/dd.c:558 [en línea] [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751 [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781 [ ] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898 [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427 [] __device_attach+0x122/0 controladores x260/base /dd.c:969 [] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487 [] device_add+0x5fb/0xdf0 drivers/base/core.c:3359 [] usb_set_configuration +0x9d9/0xb90 drivers/usb/core/message.c:2170 [] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 ERROR: pérdida de memoria objeto sin referencia 0xffff888116f06900 (tamaño 32): comm " kworker/0:2", pid 2670, jiffies 4294944448 (edad 7,160 s) volcado hexadecimal (primeros 32 bytes): 75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00 usb-001:003.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ rastreo inverso: [] kstrdup+0x36/0x70 mm/util.c :60 [] kstrdup_const+0x53/0x80 mm/util.c:83 [] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48 [] kobject_set_name_vargs+0x3b/0 xe0 lib/kobject. c:289 [] dev_set_name+0x63/0x90 drivers/base/core.c:3147 [] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535 [] __devm_mdiobus_ registrarse+ 0x75/0xf0 controladores/net/phy/mdio_devres.c:87 [] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [en línea] [] ax88772_bind+0x330/0x480 controladores/net/usb / asix_devices.c:786 [] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [] call_driver_probe drivers/base/dd.c:517 [en línea] []realmente_probe.part.0+0xe7/0x380 drivers/base/dd.c:596 []realmente_probe drivers/base/dd. c:558 [en línea] [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751 [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781 [] tacómetro +0xf6/0x140 drivers/base/dd.c:898 [] bus_for_each ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: corrige el bloqueo para el vaciado del seguimiento de la marca de tiempo de Tx. Commit 4dd0d5c33c3e ("ice: agrega bloqueo alrededor del vaciado del rastreador de marca de tiempo de Tx") agregó un bloqueo alrededor del flujo del rastreador de marca de tiempo de Tx que se utiliza para la sanitización. cualquier SKB sobrante y prepárese para retirar el dispositivo. Este bloqueo es problemático porque se mantiene en torno a una llamada a ice_clear_phy_tstamp. La función de borrado requiere un mutex para enviar un comando de escritura PHY al firmware. Esto podría llevar a un punto muerto si el mutex realmente duerme y causa la siguiente advertencia en un kernel con la depuración de prioridad habilitada: [715.419426] ERROR: función de dormir llamada desde un contexto no válido en kernel/locking/mutex.c:573 [715.427900] in_atomic (): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, nombre: rmmod [715.435652] INFORMACIÓN: lockdep está desactivado. [715.439591] Prelación deshabilitada en: [715.439594] [<0000000000000000>] 0x0 [715.446678] CPU: 52 PID: 3100 Comm: rmmod Contaminado: GW OE 5.15.0-rc4+ #42 bdd7ec3018e725f 159ca0d372ce8c2c0e784891c [ 715.458058] Nombre del hardware: Intel Corporation S2600STQ/ S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 06/01/2020 [715.468483] Seguimiento de llamadas: [715.470940] dump_stack_lvl+0x6a/0x9a [715.474613] ___might_sleep. frío+0x224/0x26a [ 715.478895] __mutex_lock+0xb3/0x1440 [ 715.482569] ? stack_depot_save+0x378/0x500 [715.486763]? ice_sq_send_cmd+0x78/0x14c0 [hielo 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.494979]? kfree+0xc1/0x520 [ 715.498128] ? mutex_lock_io_nested+0x12a0/0x12a0 [715.502837]? kasan_set_free_info+0x20/0x30 [715.507110]? __kasan_slab_free+0x10b/0x140 [715.511385] ? slab_free_freelist_hook+0xc7/0x220 [715.516092]? kfree+0xc1/0x520 [ 715.519235] ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.527359]? ice_remove+0x1cf/0x6a0 [hielo 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.535133]? pci_device_remove+0xab/0x1d0 [715.539318]? __device_release_driver+0x35b/0x690 [715.544110] ? driver_detach+0x214/0x2f0 [715.548035]? bus_remove_driver+0x11d/0x2f0 [715.552309]? pci_unregister_driver+0x26/0x250 [715.556840]? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.564799]? __do_sys_delete_module.constprop.0+0x2d8/0x4e0 [715.570554]? do_syscall_64+0x3b/0x90 [715.574303]? entrada_SYSCALL_64_after_hwframe+0x44/0xae [715.579529]? start_flush_work+0x542/0x8f0 [715.583719]? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.591923] ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc 7da2b3786a421d] [715.599960]? wait_for_completion_io+0x250/0x250 [715.604662]? lock_acquire+0x196/0x200 [715.608504]? do_raw_spin_trylock+0xa5/0x160 [715.612864] ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.620813]? ice_reset+0x130/0x130 [hielo 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.628497]? __debug_check_no_obj_freed+0x1e8/0x3c0 [715.633550]? trace_hardirqs_on+0x1c/0x130 [715.637748] ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.646220]? do_raw_spin_trylock+0xa5/0x160 [715.650581]? ice_ptp_release+0x910/0x910 [hielo 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.658797]? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.667013] ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3 786a421d] [715.675403] ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.683440] ice_remove+0x560/0x6a0 [ice 9a7e1ec00971 c89ecd3fe0d4dc7da2b3786a421d] [715.691037]? _raw_spin_unlock_irqrestore+0x46/0x73 [ 715.696005] pci_device_remove+0xab/0x1d0 [ 715.700018] __device_release_driver+0x35b/0x690 [ 715.704637] driver_detach+0x214/0x2f0 [ 715 .708389] bus_remove_driver+0x11d/0x2f0 [ 715.712489] pci_unregister_driver+0x26/0x250 [ 71 --- truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: corrige el recuento de PGD de etapa 2 del host La librería de tablas de páginas de KVM vuelve a contar las páginas de los PGD de etapa 2 concatenados individualmente. Sin embargo, cuando se ejecuta KVM en modo protegido, EL2 administra actualmente el PGD de etapa 2 del host como una única página compuesta de alto orden, lo que puede causar que el recuento de las páginas finales llegue a 0 cuando no debería, corrompiendo así el tabla de páginas. Solucione este problema introduciendo un nuevo asistente hyp_split_page() en el asignador de páginas EL2 (que coincida con la función split_page() del kernel) y utilícelo desde host_s2_zalloc_pages_exact().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: xt_IDLETIMER: corrige el pánico que ocurre cuando timer_type tiene valor basura Actualmente, cuando se agrega la regla relacionada con IDLETIMER, kmalloc inicializa la estructura del temporizador idletimer_tg al ejecutar la función idletimer_tg_create. Sin embargo, en este proceso timer->timer_type no está definido en un valor específico. Por lo tanto, timer->timer_type tiene un valor basura y se produce un pánico en el kernel. Entonces, esta confirmación soluciona el pánico al inicializar timer->timer_type usando kzalloc en lugar de kmalloc. Comandos de prueba: # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test $ cat /sys/class/xt_idletimer/timers/test Killed Splat se ve así: ERROR: KASAN: acceso a memoria de usuario en alarm_expires_remaining+0x49/ 0x70 Lectura del tamaño 8 en la dirección 0000002e8c7bc4c8 por tarea cat/917 CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 009), BIOS 1.13.0- 1ubuntu1.1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x6e/0x9c kasan_report.cold+0x112/0x117 ? alarm_expires_remaining+0x49/0x70 __asan_load8+0x86/0xb0 alarm_expires_remaining+0x49/0x70 idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d] tr_show+0x3c/0x60 sysfs_kf_seq_show+0x11d/0x1f0 ? device_remove_bin_file+0x20/0x20 kernfs_seq_show+0xa4/0xb0 seq_read_iter+0x29c/0x750 kernfs_fop_read_iter+0x25a/0x2c0 ? __fsnotify_parent+0x3d1/0x570? iov_iter_init+0x70/0x90 new_sync_read+0x2a7/0x3d0? __x64_sys_llseek+0x230/0x230 ? rw_verify_area+0x81/0x150 vfs_read+0x17b/0x240 ksys_read+0xd9/0x180 ? vfs_write+0x460/0x460? do_syscall_64+0x16/0xc0? lockdep_hardirqs_on+0x79/0x120 __x64_sys_read+0x43/0x50 do_syscall_64+0x3b/0xc0 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f0cdc819142 Código: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 RSP: :00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 000000000020000 RCX: 00007f0cdc819142 RDX: 0000000000020000 RSI: 00007f0cdc03200 0 RDI: 0000000000000003 RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: 0000000000000000 R10: 0000000000000022 R11: 00000000000000246 R 12: 00005607e9ee31f0 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: omitir eventos de netdev generados al eliminar netns syzbot informó lo siguiente (inofensivo) ADVERTENCIA: ADVERTENCIA: CPU: 1 PID: 2648 en net/netfilter/core.c:468 nft_netdev_unregister_hooks net/netfilter/nf_tables_api.c:230 [en línea] nf_tables_unregister_hook include/net/netfilter/nf_tables.h:1090 [en línea] __nft_release_basechain+0x138/0x640 net/netfilter/nf_tables_api.c:9524 nft_netdev_event net/netfilter/nft_ filtro_cadena.c: 351 [en línea] nf_tables_netdev_event+0x521/0x8a0 net/netfilter/nft_chain_filter.c:382 reproductor: dejar de compartir -n bash -c 'ip link agregar puente tipo br0; nft agregar tabla netdev t; \ nft add chain netdev t ingress \{ tipo filtro gancho ingreso dispositivo "br0" \ prioridad 0\; caída de la política\; \}' El problema es que cuando los ganchos de salida del dispositivo netns crean el evento UNREGISTER, el gancho .pre_exit para nf_tables core ya ha eliminado el gancho base. Notifier intenta hacer esto nuevamente. La necesidad de cancelar el registro del enlace base incondicionalmente era necesaria en el pasado, porque el notificador era la última etapa donde la desreferencia reg->dev era segura. Ahora que nf_tables elimina el gancho en .pre_exit, esto ya no es necesario.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: Evite fallas por IDA innecesario libre en la ruta de eliminación, hay un intento de liberar el IDA aux_idx, ya sea que esté asignado o no. Potencialmente, esto puede provocar un bloqueo al descargar el controlador en sistemas que no inicializan la compatibilidad con RDMA. Sin embargo, esta liberación no puede ser controlada por el bit de estado para RDMA, ya que se asigna si el controlador detecta soporte para RDMA en el momento de la prueba, pero el controlador puede entrar en un estado en el que RDMA no es compatible después de que se haya asignado el IDA en el momento de la prueba. tiempo y esto provocaría una pérdida de memoria. Inicialice aux_idx con un valor no válido y verifique si hay un valor válido al descargar para determinar si es necesaria una IDA libre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/smp: no disminuye el recuento de prioridad de tareas inactivas en la CPU fuera de línea Con PREEMPT_COUNT=y, cuando una CPU está fuera de línea y luego vuelve a estar en línea, obtenemos: ERROR: programación mientras es atómica: swapper/1/0/0x00000000 no hay bloqueos retenidos por swapper/1/0. CPU: 1 PID: 0 Comunicaciones: swapper/1 No contaminado 5.15.0-rc2+ #100 Seguimiento de llamadas: dump_stack_lvl+0xac/0x108 __schedule_bug+0xac/0xe0 __schedule+0xcf8/0x10d0 Schedule_idle+0x3c/0x70 do_idle+0x2d8/0x4a0 entrada_arriba+ 0x38/0x40 start_secondary+0x2ec/0x3a0 start_secondary_prolog+0x10/0x14 Esto se debe a que arch_cpu_idle_dead() de powerpc disminuye el recuento de apropiación de tareas inactivas, por razones explicadas en el commit a7c2bb8279d2 ("powerpc: volver a habilitar la apropiación antes de cpu_die()"), específicamente " start_secondary() espera un preempt_count() de 0." Sin embargo, desde el commit 2c669ef6979c ("powerpc/preempt: no toque el preempt_count de la tarea inactiva durante la conexión en caliente") y el commit f1a0a376ca0c ("sched/core: inicialice la tarea inactiva con la preferencia deshabilitada"), esa justificación ya no se cumple. No se supone que la tarea inactiva vuelva a habilitar la preferencia, por lo tanto, elimine el preempt_enable() residual de la ruta fuera de línea de la CPU. Probado con pseries y powernv en qemu y pseries en PowerVM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: pico_pci: pico_pci_remove(): arreglar UAF Cuando se elimina el módulo peek_pci, hacer referencia a 'chan' nuevamente después de liberar 'dev' causará UAF. Solucione este problema lanzando 'dev' más tarde. El siguiente registro lo revela: [35.961814] ERROR: KASAN: uso después de liberar en pico_pci_remove+0x16f/0x270 [peak_pci] [35.963414] Lectura de tamaño 8 en addr ffff888136998ee8 por tarea modprobe/5537 [35.965513] Seguimiento de llamadas: [3 5.965718 ] dump_stack_lvl+0xa8/0xd1 [35.966028] print_address_description+0x87/0x3b0 [35.966420] kasan_report+0x172/0x1c0 [35.966725]? pico_pci_remove+0x16f/0x270 [pico_pci] [35.967137]? trace_irq_enable_rcuidle+0x10/0x170 [35.967529]? pico_pci_remove+0x16f/0x270 [pico_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] pico_pci_remove+0x16f/0x270 [pico_pci] [ 35.968752 ] ve+0xa9/0x250

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: isotp: isotp_sendmsg(): agregar verificación de resultado para wait_event_interruptible() Usar wait_event_interruptible() para esperar la transmisión completa, pero no verificar el resultado de wait_event_interruptible() que puede ser interrumpido. Dará como resultado que el búfer TX tenga múltiples accesos y el proceso posterior interfiera con el proceso anterior. El siguiente es uno de los problemas informados por syzbot. ==================================================== =========== ADVERTENCIA: CPU: 0 PID: 0 en net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0 CPU: 0 PID: 0 Comm: swapper/0 No contaminado 5.13.0 -rc7+ #68 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 01/04/2014 RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0 Seguimiento de llamadas: ? isotp_setsockopt+0x390/0x390 __hrtimer_run_queues+0xb8/0x610 hrtimer_run_softirq+0x91/0xd0 ? rcu_read_lock_sched_held+0x4d/0x80 __do_softirq+0xe8/0x553 irq_exit_rcu+0xf8/0x100 sysvec_apic_timer_interrupt+0x9e/0xc0 asm_sysvec_apic_timer_interrupt+0x12/0x20 Agregar verificación de resultado para wait_event_ interrumpible() en isotp_sendmsg() para evitar múltiples accesos al búfer tx.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: el montaje falla con desbordamiento del búfer en strlen. A partir del kernel 5.11 compilado con CONFIG_FORTIFY_SOURCE, la conexión de un sistema de archivos ocfs2 con una pila de clúster o2cb o pcmk falla con el siguiente seguimiento. El problema parece ser que no se garantiza que las cadenas para la pila del clúster y el nombre del clúster tengan terminación nula en la representación del disco, mientras que strlcpy supone que la cadena de origen siempre termina en nulo. Esto provoca una lectura fuera de la cadena de origen que activa la detección de desbordamiento del búfer. se detectó desbordamiento del búfer en strlen ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/string.c:1149! código de operación no válido: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 No contaminado 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortify_panic+0xf/0x11... Seguimiento de llamadas: ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2] ocfs2_fill_super+0x359/0x19b0 [ocfs2] mount_bdev+0x185/0x1b0 Legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 xa20 __x64_sys_mount+0x103/0x140 do_syscall_64+0x3b/0xc0 entrada_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: j1939_netdev_start(): arreglar UAF para rx_kref de j1939_priv Activará UAF para rx_kref de j1939_priv de la siguiente manera. cpu0 cpu1 j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...) j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref , ...) REFCOUNT_WARN("adición en 0;...") ================================== ==================== refcount_t: suma en 0; use-after-free. ADVERTENCIA: CPU: 1 PID: 20874 en lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP: 0010:refcount_warn_saturate+0x169/0x1e0 Seguimiento de llamadas: j1939_netdev_start+0x68b/0x920 j1939_sk_bind+0x426 /0xeb0 ? security_socket_bind+0x83/0xb0 Los kref_get() y kref_put() de rx_kref deben usar j1939_netdev_lock para proteger.