Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/packet: corrige el acceso slab-out-of-bounds en paquete_recvmsg() syzbot descubrió que cuando un socket AF_PACKET utiliza operaciones PACKET_COPY_THRESH y mmap, tpacket_rcv() está poniendo en cola skbs con basura en skb->cb[], lo que desencadena una copia demasiado grande [1] Presumiblemente, los usuarios de af_packet que usan mmap() ya obtienen los metadatos correctos del búfer asignado, simplemente podemos asegurarnos de borrar 12 bytes que podrían copiarse al usuario espacio más tarde. ERROR: KASAN: pila fuera de los límites en memcpy include/linux/fortify-string.h:225 [en línea] ERROR: KASAN: pila fuera de los límites en paquete_recvmsg+0x56c/0x1150 net/packet/af_packet. c:3489 Escritura de tamaño 165 en la dirección ffffc9000385fb78 por tarea syz-executor233/3631 CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0 Nombre de hardware: Google Google Compute Engine /Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf /0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [en línea] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [en línea] paquete_recvmsg+0x56c/ 0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [en línea] sock_recvmsg net/socket.c:966 [en línea] sock_recvmsg net/socket.c:962 [en línea] ____sys_recvmsg+0x2c4/0x600 net/ socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] arco xb0 /x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdfd5954c29 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf8e71e48 EFLAGS: 0000246 ORIG_RAX: 000000000000002f RAX : ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 000000000000005 RBP: 0000000 000000000 R08: 000000000000000d R09: 000000000000000d R10: 0000000000000000 R11: 00000000000000246 R12: 00007ffcf8e71e60 R13: 0000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 dirección ffffc9000385fb78 está ubicado en la pila de la tarea syz-executor233/3631 en el desplazamiento 32 en el marco: ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246 este marco tiene 1 objeto: [32, 160) 'addr' Estado de memoria alrededor del buggy dirección: ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 c9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 ^ ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 0 0 00 00 00 00 ====== ==================================================== ==========

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iavf: corrige el bloqueo durante el reinicio/apagado. El commit reciente 974578017fc1 ("iavf: agrega espera para que el puerto se inicialice en eliminar") agrega un bucle de espera al comienzo de iavf_remove() para garantizar que la inicialización del puerto finalice antes de cancelar el registro del dispositivo de red. Esto provoca una regresión en el escenario de reinicio/apagado porque en este caso se llama a la devolución de llamada iavf_shutdown() y esta devolución de llamada desconecta el dispositivo, lo desactiva si se está ejecutando y establece su estado en __IAVF_REMOVE. Posteriormente se llama a la devolución de llamada de apagado del controlador PF asociado (por ejemplo, ice_shutdown). Esa devolución de llamada llama, entre otras cosas, a sriov_disable() que llama indirectamente a iavf_remove() (consulte el seguimiento de la pila a continuación). Como el estado del adaptador ya es __IAVF_REMOVE, el bucle mencionado no tiene fin y el proceso de apagado se bloquea. El parche soluciona este problema verificando el estado del adaptador al comienzo de iavf_remove() y omite el resto de la función si el adaptador ya está en estado de eliminación (el apagado está en curso). Reproductor: 1. Cree VF en PF controlado por el controlador ice o i40e 2. Asegúrese de que el VF esté vinculado al controlador iavf 3. Reinicie [52625.981294] sysrq: SysRq: Mostrar estado bloqueado [52625.988377] tarea: estado de reinicio: pila D: 0 pid:17359 ppid: 1 f2 [52625.996732] Seguimiento de llamadas: [52625.999187] __schedule+0x2d1/0x830 [52626.007400] Schedule+0x35/0xa0 [52626.010545] Schedule_hrtimeout_range_clock+0x83/0x100 2626.020046] usleep_range+0x5b/0x80 [52626.023540] iavf_remove+ 0x63/0x5b0 [iavf] [52626.027645] pci_device_remove+0x3b/0xc0 [52626.031572] device_release_driver_internal+0x103/0x1f0 [52626.036805] pci_stop_bus_device+0x72/0xa0 [52626. 040904] pci_stop_and_remove_bus_device+0xe/0x20 [52626.045870] pci_iov_remove_virtfn+0xba/0x120 [52626.050232] sriov_disable +0x2f/0xe0 [52626.053813] ice_free_vfs+0x7c/0x340 [hielo] [52626.057946] ice_remove+0x220/0x240 [hielo] [52626.061967] ice_shutdown+0x16/0x50 [52626.06598 7] pci_device_shutdown+0x34/0x60 [52626.070086] dispositivo_shutdown+ 0x165/0x1c5 [52626.074011] kernel_restart+0xe/0x30 [52626.077593] __do_sys_reboot+0x1d2/0x210 [52626.093815] do_syscall_64+0x5b/0x1a0 [52626.097483] entrada_SYSCALL_64_after_hwframe+0x65/0xca

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la desreferencia del puntero NULL en ice_update_vsi_tx_ring_stats() Es posible realizar la desreferencia del puntero NULL en la rutina que actualiza las estadísticas del anillo Tx. Actualmente, solo se actualizan las estadísticas y los bytes cuando el puntero del anillo es válido, pero más adelante se accede al anillo para propagar las estadísticas de Tx recopiladas en las estadísticas de VSI. Cambie la lógica existente para pasar al siguiente anillo cuando el anillo sea NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la condición de ejecución durante la esclavitud de la interfaz. El commit 5dbbbd01cbba83 ("ice: evita el bloqueo RTNL al recrear el dispositivo auxiliar") cambia el proceso de recreación del dispositivo auxiliar para que ice_plug_aux_dev( ) se llama desde el contexto ice_service_task(). Desafortunadamente, esto abre una ventana de ejecución que puede resultar en un punto muerto cuando la interfaz sale de LAG e inmediatamente ingresa a LAG nuevamente. Reproductor: ``` #!/bin/sh enlace ip agregar lag0 tipo modo de enlace 1 miimon 100 enlace ip configurar lag0 para n en {1..10}; do echo Cycle: $n ip link set ens7f0 master lag0 sleep 1 ip link set ens7f0 nomaster done ``` Esto da como resultado: [20976.208697] Cola de trabajo: ice ice_service_task [ice] [20976.213422] Seguimiento de llamadas: [20976.215871] __schedule+0x2d1/ 0x830 [20976.219364] programación+0x35/0xa0 [20976.222510] programación_preempt_disabled+0xa/0x10 [20976.227043] __mutex_lock.isra.7+0x310/0x420 [20976.235071] enum_all_gids_of_de v_cb+0x1c/0x100 [ib_core] [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core ] [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core] [20976.261079] ib_register_device+0x40d/0x580 [ib_core] [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma] 0976.281409] irdma_probe+0x2c1/0x360 [irdma] [20976.285691] sonda_bus_auxiliar+ 0x45/0x70 [20976.289790] very_probe+0x1f2/0x480 [20976.298509] driver_probe_device+0x49/0xc0 [20976.302609] bus_for_each_drv+0x79/0xc0 [20976.306448] adjuntar+0xdc/0x160 [20976.310286] bus_probe_device+0x9d/0xb0 [20976.314128] dispositivo_add+0x43c/ 0x890 [20976.321287] __auxiliary_device_add+0x43/0x60 [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice] [20976.330109] ice_service_task+0xd0c/0xed0 [ice] 1] proceso_un_trabajo+0x1a7/0x360 [20976.350536] hilo_trabajador+0x30/0x390 [20976.358128] kthread+0x10a/0x120 [20976.365547] ret_from_fork+0x1f/0x40 ... [20976.438030] tarea:ip estado:D pila: 0 pid:213658 ppid:213627 banderas:0x00004084 [20976.446469] Seguimiento de llamadas: 76.448921] __programación+0x2d1/ 0x830 [20976.452414] programación+0x35/0xa0 [20976.455559] programación_preempt_disabled+0xa/0x10 [20976.460090] __mutex_lock.isra.7+0x310/0x420 [20976.464364 dispositivo_del+0x36/0x 3c0 [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [hielo] [20976.472313 ] ice_lag_event_handler+0x2a2/0x520 [ice] [20976.477288] notifier_call_chain+0x47/0x70 [20976.481386] __netdev_upper_dev_link+0x18b/0x280 [20976.489845] bond_enslave+0xe05/0 x1790 [vinculación] [20976.494475] do_setlink+0x336/0xf50 [20976.502517] __rtnl_newlink+0x529 /0x8b0 [20976.543441] rtnl_newlink+0x43/0x60 [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360 [20976.559238] netlink_rcv_skb+0x4c/0x120 [20976.563079] _unicast+0x196/0x230 [20976.567005] netlink_sendmsg+0x204/0x3d0 [20976.570930] sock_sendmsg+0x4c/0x50 [20976.574423] ____sys_sendmsg+0x1eb/0x250 [20976.586807] ___sys_sendmsg+0x7c/0xc0 [20976.606353] __sys_sendmsg+0x57/0xa0 [20976.609930] call_64+0x5b/0x1a0 [20976.613598] Entry_SYSCALL_64_after_hwframe+0x65/0xca 1. Comando 'ip link... set nomaster' provoca que se llame a ice_plug_aux_dev() desde el contexto ice_service_task(), se crea el dispositivo auxiliar y se toma el dispositivo asociado->bloqueo. 2. El comando 'ip link... set master...' llama al notificador de ice bajo bloqueo RTNL y ese notificador llama a ice_unplug_aux_dev(). Esa función intenta tomar el dispositivo auxiliar->bloqueo, pero esto ya lo tomó ice_plug_aux_dev() en el paso 1 3. Más tarde, ice_plug_aux_dev() intenta tomar el bloqueo RTNL pero esto ya lo tomó en el paso 2 4. Bloqueo muerto El parche soluciona esto problema mediante los siguientes cambios: - El bit ICE_FLAG_PLUG_AUX_DEV se mantiene configurado durante la llamada a ice_plug_aux_dev() en ice_service_task() - El bit se verifica en ice_clear_rdma_cap() y solo si no está configurado, se llama a ice_unplug_aux_dev(). l ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_core: corrige la fuga de sent_cmd skb La memoria sent_cmd no se libera antes de liberar hci_dev, lo que provoca que se filtre su contenido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: MIPS: smp: complete los mapas de hermanos y núcleos antes Después de habilitar CONFIG_SCHED_CORE (aterrizado durante el ciclo 5.14), se inició interAptiv de 2 núcleos y 2 subprocesos por núcleo (controlado por CPS) emitiendo lo siguiente: [0.025698] La revisión de CPU1 es: 0001a120 (MIPS interAptiv (multi)) [0.048183] ------------[ cortar aquí ]------------ [0.048187] ADVERTENCIA: CPU: 1 PID: 0 en kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [0.048220] Módulos vinculados en: [0.048233] CPU: 1 PID: 0 Comm: swapper/1 No contaminado 5.17 .0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [0.048247] Pila: 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc 4 00000000 00000000 00000000 00000000 00000000 [ 0,048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... 0.048396] Seguimiento de llamadas: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60 /0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] 198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting +0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] _secundario+0xbc/0x280 [ 0,048539] [ 0,048543] - --[ end trace 0000000000000000 ]--- [ 0.048636] Sincronizar contadores para CPU 1: hecho. ...para cada uno menos CPU 0/arranque. Las impresiones de depuración básicas justo antes de la línea mencionada dicen: [0.048170] CPU: 1, smt_mask: Entonces smt_mask, que obviamente es una máscara hermana, está vacía al ingresar a la función. Esto es crítico, ya que sched_core_cpu_starting() calcula los parámetros de programación central solo una vez por inicio de CPU, y es crucial tener todos los parámetros completados en ese momento (al menos usa cpu_smt_mask() que de hecho es `&cpu_sibling_map[cpu]` en MIPS). Un poco de depuración me llevó a que set_cpu_sibling_map() realizaba el cálculo del mapa real, se invocaba después de notify_cpu_start(), y exactamente la última función inicia la ronda de devolución de llamada de CPU HP (sched_core_cpu_starting() es básicamente una devolución de llamada de CPU HP). Si bien el flujo es el mismo en ARM64 (mapas después del notificador, aunque antes de llamar a set_cpu_online()), x86 comenzó a calcular mapas de hermanos antes de iniciar las devoluciones de llamada de CPU HP en Linux 4.14 (consulte [0] para la referencia). Ni yo ni mis breves pruebas pudimos encontrar posibles advertencias al calcular los mapas justo después de realizar la calibración de retraso, pero el símbolo WARN ya no está. Las mismas impresiones de depuración ahora producen exactamente lo que esperaba de ellas: [0.048433] CPU: 1, smt_mask: 0-1 [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips /linux.git/commit/?id=76ce7cfe35ef

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: liberar estructuras rq qos para cola sin disco blkcg_init_queue() puede agregar estructuras rq qos para solicitar cola, previamente blk_cleanup_queue() llama a rq_qos_exit() para liberarlas, pero commit 8e141f9eb803 ( "bloque: drenar la E/S del sistema de archivos en del_gendisk") mueve rq_qos_exit() a del_gendisk(), por lo que la pérdida de memoria se debe a que es posible que las colas no tengan disco, como los luns scsi no presentes, la cola de administración de nvme, ... solucione el problema agregando rq_qos_exit() a blk_cleanup_queue() nuevamente. Por cierto, v5.18 ya no necesitará este parche ya que movemos blkcg_init_queue()/blkcg_exit_queue() al controlador de asignación/liberación de disco, y los parches han estado en for-5.18/block.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: watch_queue: corrige la verificación del límite del filtro En watch_queue_set_filter(), hay un par de lugares donde verificamos que el valor del tipo de filtro no exceda lo que puede contener el mapa de bits type_filter. Un lugar calcula el número de bits mediante: if (tf[i].type >= sizeof(wfilter->type_filter) * 8) lo cual está bien, pero el segundo sí: if (tf[i].type >= sizeof( wfilter->type_filter) * BITS_PER_LONG) que no lo es. Esto puede provocar un par de escrituras fuera de los límites debido a un tipo demasiado grande: (1) __set_bit() en wfilter->type_filter (2) Escribir más elementos en wfilter->filters[] de los que asignamos. Solucione este problema simplemente usando el WATCH_TYPE__NR adecuado, que es la cantidad de tipos que realmente conocemos. El error puede provocar un error parecido a: ERROR: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740 Escritura de tamaño 4 en la dirección ffff88800d2c66bc mediante la tarea watch_queue_oob/611... Seguimiento de llamadas: dump_stack_lvl+ 0x45/0x59 print_address_description.constprop.0+0x1f/0x150 ... kasan_report.cold+0x7f/0x11b ... watch_queue_set_filter+0x659/0x740 ... __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 entrada_ SYSCALL_64_after_hwframe+0x44/0xae Asignado por tarea 611: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 watch_queue_set_filter+0x23a/0x740 __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 Entry_SYSCALL_64_after_hwframe+0x 44/0xae La dirección con errores pertenece al objeto en ffff88800d2c66a0 que pertenece al caché kmalloc-32 de tamaño 32 La dirección con errores se encuentra a 28 bytes dentro de la región de 32 bytes [ffff88800d2c66a0, ffff88800d2c66c0)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vrr: establezca la propiedad con capacidad de VRR solo si está conectada al conector. La propiedad con capacidad de VRR no está conectada de manera predeterminada al conector. Se conecta solo si se admite VRR. Entonces, si el controlador intenta llamar a la función drm core set prop sin que esté adjunta, eso causa una desreferencia NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: omite la advertencia de bytes reservados al desmontar después de un error en la limpieza del registro Después de los cambios recientes realizados por El commit c2e39305299f01 ("btrfs: borra la actualización del búfer de extensión cuando no podemos escribirlo") y su corrección de seguimiento, commit 651740a5024117 ("btrfs: verifique WRITE_ERR al intentar leer un búfer de extensión"), ahora podemos terminar sin limpiar las reservas de espacio de los búferes de extensión del árbol de registro después de que se produzca una cancelación de transacción, además de no limpiar los búferes de extensión aún sucios. Esto sucede porque si falla la reescritura para un búfer de extensión de árbol de registro, entonces hemos borrado el bit EXTENT_BUFFER_UPTODATE del búfer de extensión y también hemos configurado el bit EXTENT_BUFFER_WRITE_ERR en él. Más adelante, al intentar liberar el árbol de registro con free_log_tree(), que itera sobre el árbol, podemos terminar obteniendo un error -EIO al intentar leer un nodo o una hoja, ya que read_extent_buffer_pages() devuelve -EIO si es una extensión. El búfer no tiene EXTENT_BUFFER_UPTODATE establecido y tiene el bit EXTENT_BUFFER_WRITE_ERR establecido. Obtener eso -EIO significa que regresamos inmediatamente ya que no podemos iterar sobre todo el árbol. En ese caso, nunca actualizamos el espacio reservado para un búfer de extensión en el grupo de bloques respectivo y el objeto space_info. Cuando esto sucede, obtenemos los siguientes rastros al desmontar el fs: [174957.284509] BTRFS: error (dispositivo dm-0) en cleanup_transaction:1913: errno=-5 IO Failure [174957.286497] BTRFS: error (dispositivo dm-0) en free_log_tree :3420: errno=-5 Fallo de E/S [174957.399379] ------------[ cortar aquí ]------------ [174957.402497] ADVERTENCIA: CPU: 2 PID: 3206883 en fs/btrfs/block-group.c:127 btrfs_put_block_group+0x77/0xb0 [btrfs] [174957.407523] Módulos vinculados en: btrfs overlay dm_zero (...) [174957.424917] CPU: 2 PID: 3206883 Comm: umount Tain Ted: GW 5.16.0-rc5-btrfs-next-109 #1 [174957.426689] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01 /2014 [174957.428716] RIP: 0010:btrfs_put_block_group+0x77/0xb0 [btrfs] [174957.429717] Código: 21 48 8b bd (...) [174957.432867] RSP: 0018:ffffb70d41cffdd0 EFLAGS: 00010206 [174957.433632] RAX: 0000000000000001 RBX: ffff8b09c3848000 RCX: ffff8b0758edd1c8 [174957.434689] RDX: 0000000000000001 RSI: ffffffffc0b467e7 RDI: ffff8b0758edd000 [174957.436068] RBP: b0758edd000 R08: 0000000000000000 R09: 0000000000000000 [174957.437114] R10: 0000000000000246 R11: 0000000000000000 R12: 8148 [174957.438140] R13: ffff8b09c3848198 R14: ffff8b0758edd188 R15 : muerto000000000100 [174957.439317] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS:0000000000000000 [174957.440402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [174957.441164] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000370ee0 [174957.442117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [174957.443076] DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 000000400 [174957.443948] Seguimiento de llamadas: [174957.444264] [174957.444538] btrfs_free_block_groups+0x255/0x3c0 [btrfs] [174957.445238] close_ctree+0x301 /0x357 [btrfs] [174957.445803] ? call_rcu+0x16c/0x290 [174957.446250] generic_shutdown_super+0x74/0x120 [174957.446832] kill_anon_super+0x14/0x30 [174957.447305] btrfs_kill_super+0x12/0x20 [btrfs] 957.447890] desactivar_locked_super+0x31/0xa0 [174957.448440] cleanup_mnt+0x147/0x1c0 [174957.448888 ] task_work_run+0x5c/0xa0 [174957.449336] exit_to_user_mode_prepare+0x1e5/0x1f0 [174957.449934] syscall_exit_to_user_mode+0x16/0x40 [174957.450512] do_syscall_64+0x48/0 xc0 [174957.450980] Entry_SYSCALL_64_after_hwframe+0x44/0xae [174957.451605] RIP: 0033:0x7f328fdc4a97 [174957.452059] Código : 03 0c 00 f7 (...) [174957.454320] RSP: 002b:00007fff13564ec8 EFLAGS: 00000246 ---truncado- --

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: usbtmc: corrige un error en la dirección de la tubería para las transferencias de control. El syzbot fuzzer informó un error menor en el controlador usbtmc: usb 5-1: directorio de control BOGUS, la tubería 80001e80 no coincide con bRequestType 0 ADVERTENCIA: CPU: 0 PID: 3813 en drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Módulos vinculados en: CPU: 0 PID: 3813 Comm : syz-executor122 No contaminado 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Seguimiento de llamadas: usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core /message.c:102 [en línea] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [en línea] El problema es que usbtmc_ioctl_request() usa usb_rcvctrlpipe( ) para todas sus transferencias, ya sean de entrada o de salida. Es fácil de arreglar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: evitar doble fput() en copia de usuario fallida. Si la copia al área de usuario falla para FASTRPC_IOCTL_ALLOC_DMA_BUFF ioctl(), no debemos asumir que 'buf->dmabuf' aun es válido. De hecho, dma_buf_fd() llamó a fd_install() antes, es decir, "consumió" una referencia, dejándonos sin ninguna. Por lo tanto, llamar a dma_buf_put() colocará una referencia que ya no poseemos, lo que conducirá a una entrada válida en la tabla de descripción de archivos para un objeto 'archivo' ya publicado que es un use-after-free directo. Simplemente evite llamar a dma_buf_put() y confíe en el código de salida del proceso para realizar la limpieza necesaria, si es necesario, es decir, si el descriptor del archivo aún es válido.