Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tun: llamar a napi_schedule_prep() para asegurarnos de que poseemos un napi Un parche reciente expuso otro problema en napi_get_frags() detectado por syzbot [1] Antes de alimentar paquetes a GRO y llamar a napi_complete(), primero debemos obtener NAPI_STATE_SCHED. [1] ADVERTENCIA: CPU: 0 PID: 3612 en net/core/dev.c:6076 napi_complete_done+0x45b/0x880 net/core/dev.c:6076 Módulos vinculados: CPU: 0 PID: 3612 Comm: syz-executor408 No contaminado 6.1.0-rc3-syzkaller-00175-g1118b2049d77 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 RIP: 0010:napi_complete_done+0x45b/0x880 net/core/dev.c:6076 Código: c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 24 04 00 00 41 89 5d 1c e9 73 fc ff ff e8 b5 53 22 fa <0f> 0b e9 82 fe ff ff e8 a9 53 22 fa 48 8b 5c 24 08 31 ff 48 89 de RSP: 0018:ffffc90003c4f920 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000030 RCX: 000000000000000 RDX: ffff8880251c0000 RSI: ffffffff875a58db RDI: 0000000000000007 RBP: 0000000000000001 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888072d02628 R13: ffff888072d02618 R14: ffff888072d02634 R15: 0000000000000000 FS: 0000555555f13300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055c44d3892b8 CR3: 00000000172d2000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: napi_complete include/linux/netdevice.h:510 [inline] tun_get_user+0x206d/0x3a60 drivers/net/tun.c:1980 tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2027 call_write_iter include/linux/fs.h:2191 [inline] do_iter_readv_writev+0x20b/0x3b0 fs/read_write.c:735 do_iter_write+0x182/0x700 fs/read_write.c:861 vfs_writev+0x1aa/0x630 fs/read_write.c:934 do_writev+0x133/0x2f0 fs/read_write.c:977 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f37021a3c19

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: marvell: prestera: se corrige una fuga de memoria en prestera_rxtx_switch_init(). Cuando prestera_sdma_switch_init() falla, la memoria a la que apunta sw->rxtx no se libera. Se debe corregir. Solo se compilará, no se probará.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ti: k3-udma-glue: corrige pérdida de memoria cuando falla el registro del dispositivo Si device_register() falla, debe llamar a put_device() para entregar la referencia, el nombre asignado en dev_set_name() se puede liberar en la función de devolución de llamada kobject_cleanup().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: mv_xor_v2: Se corrige una fuga de recursos en mv_xor_v2_remove(). Una llamada clk_prepare_enable() en la sonda no se compensa con la llamada clk_disable_unprepare() correspondiente en la función de eliminación. Agregue la llamada faltante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: Se corrige la comprobación del umbral de SQE. La forma actual de comprobar el recuento de SQE disponibles, basada en el recuento de SQB actualizado por hardware, podría provocar que el controlador envíe un SQE incluso antes de que se procese en NAPI el CQE del SQE previamente transmitido en el mismo índice, lo que resulta en la pérdida de punteros SKB y, por lo tanto, una fuga. Se soluciona esto comprobando un índice de consumidor que se actualiza una vez procesado el CQE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: lapbether: se corrige el problema de un código de operación no válido en lapbeth_open(). Si lapb_register() falla al iniciar el dispositivo lapb por primera vez, NAPI no se desactiva. Por lo tanto, el problema de código de operación no válido se reporta al iniciar el dispositivo lapb por segunda vez. La información de la pila es la siguiente: [ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442! [ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0 [ 1958.332310][T11356] Call Trace: [ 1958.332817][T11356] [ 1958.336135][T11356] lapbeth_open+0x18/0x90 [ 1958.337446][T11356] __dev_open+0x258/0x490 [ 1958.341672][T11356] __dev_change_flags+0x4d4/0x6a0 [ 1958.345325][T11356] dev_change_flags+0x93/0x160 [ 1958.346027][T11356] devinet_ioctl+0x1276/0x1bf0 [ 1958.346738][T11356] inet_ioctl+0x1c8/0x2d0 [ 1958.349638][T11356] sock_ioctl+0x5d1/0x750 [ 1958.356059][T11356] __x64_sys_ioctl+0x3ec/0x1790 [ 1958.365594][T11356] do_syscall_64+0x35/0x80 [ 1958.366239][T11356] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 1958.377381][T11356]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: j1939_send_one(): se corrige la falta de inicialización del encabezado CAN. El acceso de lectura a struct canxl_frame::len dentro de un skbuff creado con j1939 reveló la falta de inicialización de elementos reservados y posteriormente rellenados en struct can_frame. Este parche inicializa el encabezado CAN de 8 bytes con cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: Se corrige un error de escritura fuera de los límites en udf_find_entry() Syzbot informó un error de escritura fuera de los límites: loop0: se detectó un cambio de capacidad de 0 a 2048 ======================================================================= ERROR: KASAN: slab-out-of-bounds en udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 Escritura de tamaño 105 en la dirección ffff8880123ff896 por la tarea syz-executor323/3610 CPU: 0 PID: 3610 Comm: syz-executor323 No contaminado 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7ffab0d164d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Asignado por la tarea 3610: kasan_save_stack mm/kasan/common.c:45 [en línea] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [en línea] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [en línea] udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [en línea] open_last_lookups fs/namei.c:3481 [en línea] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [en línea] __do_sys_creat fs/open.c:1402 [en línea] __se_sys_creat fs/open.c:1396 [en línea] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd La dirección con errores pertenece al objeto en ffff8880123ff800 que pertenece a la caché kmalloc-256 de tamaño 256 La dirección con errores se encuentra 150 bytes dentro de la región de 256 bytes [ffff8880123ff800, ffff8880123ff900) La dirección con errores pertenece a la página física: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:000000000000000 index:0x0 pfn:0x123fe cabeza:ffffea000048ff80 orden:1 compuesto_mapcount:0 compuesto_pincount:0 banderas: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) sin formato: 00fff00000010200 ffffea00004b8500 muerto000000000003 ffff888012041b40 sin formato: 000000000000000 0000000080100010 00000001ffffffff 0000000000000000 página volcada porque: kasan: se detectó un acceso incorrecto page_owner rastrea la página como asignada última página asignada mediante orden 0, migrationtype Inamovible, gfp_---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: qcom-qmp-combo: corrección de la desreferencia de NULL al reanudar la ejecución. El commit fc64623637da ("phy: qcom-qmp-combo,usb: añadir compatibilidad con la región PCS_USB independiente") comenzó a tratar los registros PCS_USB como potencialmente independientes de los registros PCS, pero utilizaba la base incorrecta cuando no se proporcionaba un desplazamiento PCS_USB. Se corrigió la base PCS_USB utilizada al reanudar la ejecución para evitar la desreferenciación de un puntero NULL en plataformas que no proporcionan un desplazamiento PCS_USB (p. ej., SC7180).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corregir bloqueo en nilfs_count_free_blocks() Un bloqueo de semáforo puede ocurrir si nilfs_get_block() detecta corrupción de metadatos mientras localiza bloques de datos y ocurre una escritura diferida de superbloque al mismo tiempo: tarea 1 tarea 2 ------ ------ * Una operación de archivo * nilfs_truncate() nilfs_get_block() down_read(rwsem A) <-- nilfs_bmap_lookup_contig() ... generic_shutdown_super() nilfs_put_super() * Preparar para escribir superbloque * down_write(rwsem B) <-- nilfs_cleanup_super() * Detectar corrupción de árbol b * nilfs_set_log_cursor() nilfs_bmap_convert_error() nilfs_count_free_blocks() __nilfs_error() down_read(rwsem A) <-- nilfs_set_error() down_write(rwsem B) <-- *** DEADLOCK *** Aquí, nilfs_get_block() vuelve a bloquear rwsem A (= NILFS_MDT(dat_inode)->mi_sem) y luego llama a nilfs_bmap_lookup_contig(), pero si falla debido a la corrupción de metadatos, se llama a __nilfs_error() desde nilfs_bmap_convert_error() dentro de la sección de bloqueo. Dado que __nilfs_error() llama a nilfs_set_error() a menos que el sistema de archivos sea de solo lectura y nilfs_set_error() intente bloquear la escritura de rwsem B (= nilfs->ns_sem) para reescribir exclusivamente el superbloque, la adquisición del bloqueo jerárquico se produce en el orden rwsem A -> rwsem B. Ahora bien, si otra tarea comienza a actualizar el superbloque, puede bloquear la escritura de rwsem B durante la secuencia de bloqueo anterior y puede bloquearse al intentar bloquear la lectura de rwsem A en nilfs_count_free_blocks(). Sin embargo, no es necesario tomar rwsem A en nilfs_count_free_blocks() porque, dentro de la sección de bloqueo, solo lee un único dato entero en una estructura compartida con nilfs_sufile_get_ncleansegs(). Esto ha sucedido después del commit aa474a220180 ("nilfs2: añadir variable local para almacenar en caché el número de segmentos limpios"), incluso antes de que se introdujera este error. Por lo tanto, esto resuelve el problema de interbloqueo simplemente eliminando el semáforo en nilfs_count_free_blocks().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macvlan: corregir fugas de memoria de macvlan_common_newlink kmemleak informa de fugas de memoria en macvlan_common_newlink, como se indica a continuación: ip link add link eth0 name .. type macvlan mode source macaddr add kmemleak informa: objeto no referenciado 0xffff8880109bb140 (tamaño 64): comm "ip", pid 284, jiffies 4294986150 (edad 430.108s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z..... 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk seguimiento inverso: [] kmem_cache_alloc_trace+0x1c7/0x300 [] macvlan_hash_add_source+0x45/0xc0 [] macvlan_changelink_sources+0xd7/0x170 [] macvlan_common_newlink+0x38c/0x5a0 [] macvlan_newlink+0xe/0x20 [] __rtnl_newlink+0x7af/0xa50 [] rtnl_newlink+0x48/0x70 ... En el escenario donde el modo macvlan está configurado como 'origen', se ejecutará macvlan_changelink_sources() para reconfigurar la lista de direcciones MAC de origen remoto. Al mismo tiempo, si register_netdevice() devuelve un error, el recurso generado por macvlan_changelink_sources() no se limpia. Con este parche, en caso de error, se ejecutará macvlan_flush_sources() para garantizar que el recurso se limpie.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp: Se corrige una ruta de gestión de errores en mctp_init(). Si mctp_neigh_init() devuelve un error, los recursos de las rutas deben liberarse en la ruta de gestión de errores. De lo contrario, se producen fugas de recursos.