Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: lan966x: Se corrige un posible error de referencia nulo (PTR) en lan966x_stats_init(). Lan966x_stats_init() llama a create_singlethread_workqueue() y no verifica el valor ret, lo que puede devolver NULL. Podría ocurrir un error de referencia nulo (PTR): lan966x_stats_init() create_singlethread_workqueue() # Falló, lan966x->stats_queue es NULL. queue_delayed_work() queue_delayed_work_on(). __queue_delayed_work() # Advertencia, pero continúe. __queue_work() # Acceso a wq->flags, PTR-deref nulo. Verifique el valor ret y devuelva -ENOMEM si es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: microchip: sparx5: Se corrige un posible null-ptr-deref en sparx_stats_init() y sparx5_start(). sparx_stats_init() llama a create_singlethread_workqueue() y no comprueba el valor ret, lo que puede devolver NULL. Y puede ocurrir un null-ptr-deref: sparx_stats_init() create_singlethread_workqueue() # falló, sparx5->stats_queue es NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # advertencia aquí, pero continúe __queue_work() # acceso a wq->flags, null-ptr-deref Compruebe el valor ret y devuelva -ENOMEM si es NULL. Así como sparx5_start().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Se corrige la ejecución donde se pueden llamar los eprobes antes del evento. El indicador que indica al evento que llame a sus desencadenadores después de leer el evento se establece para los eprobes después de habilitarlos. Esto provoca una ejecución donde el eprobe puede activarse al inicio del evento cuando la información del registro es nula. El eprobe entonces desreferencia el registro nulo, causando un error de puntero de kernel nulo. Pruebe si hay un registro nulo para evitar que esto suceda.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Se corrige el acceso a memoria no autorizado en register_synth_event(). En register_synth_event(), si set_synth_event_print_fmt() falla, se invocarán trace_remove_event_call() y unregister_trace_event(), lo que significa que trace_event_call llamará a __unregister_trace_event() dos veces. Como resultado, la segunda anulación del registro provocará el acceso a memoria no autorizado. register_synth_event set_synth_event_print_fmt falló trace_remove_event_call event_remove si call->event.funcs entonces __unregister_trace_event (primera llamada) unregister_trace_event __unregister_trace_event (segunda llamada) Corrija el error evitando llamar al segundo __unregister_trace_event() verificando si se llama al primero. Fallo de protección general, probablemente por dirección no canónica 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: tal vez acceso a memoria salvaje en el rango [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe No contaminado 6.1.0-rc1-00186-g76f33a7eedb4 #299 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 Código: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP: 0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: muerto000000000100 R08: 0000000000000000 R09: ffffbfff0913481 R10: ffffffff8489a407 R11: ffffbfff0913480 R12: muerto000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Se corrige la fuga de memoria en test_gen_synth_cmd() y test_empty_synth_event(). Test_gen_synth_cmd() solo libera búfer en la ruta de fallo, por lo que el búfer se filtrará aunque no haya fallo. Se ha añadido kfree(buf) para evitar la fuga de memoria. La misma razón y solución se aplican en test_empty_synth_event(). objeto sin referencia 0xffff8881127de000 (size 2048): comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s) hex dump (first 32 bytes): 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_ backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<0000000039eb1cf5>] 0xffffffffa00083cd [<000000000e8c3bc8>] 0xffffffffa00086ba [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff8881127df000 (size 2048): comm "modprobe", pid 247, jiffies 4294972324 (age 78.728s) hex dump (first 32 bytes): 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<00000000d4db9a3d>] 0xffffffffa0008071 [<00000000c31354a5>] 0xffffffffa00086ce [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: Fix memory leakage in tracing_read_pipe() kmemleak informa de este problema: unreferenced object 0xffff888105a18900 (size 128): comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...BX 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] __kmalloc_nodo_rastreador_llamador+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150 [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0 [<0000000065629d9d>] trace_event_printf+0xb6/0xf0 [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0 [<00000000d22db172>] imprimir_línea_de_seguimiento+0x73c/0x1480 [<00000000cdba76ba>] conducto_de_lectura_de_seguimiento+0x45c/0x9f0 [<0000000015b58459>] lectura_vfs+0x17b/0x7c0 [<000000004aeee8ed>] lectura_ksys+0xed/0x1c0 [<0000000063d3d898>] hacer_llamada_al_sistema_64+0x3b/0x90 [<00000000a06dda7f>] entrada_SYSCALL_64_después_de_hwframe+0x63/0xcd iter->fmt asignado en conducto_de_lectura_de_seguimiento() -> .. ->trace_iter_expand_format(), pero no se libera, para solucionarlo, agregue free en tracing_release_pipe()

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: iforce - invierte la comprobación de longitud válida al obtener los ID de dispositivo. syzbot informa un valor no inicializado en iforce_init_device() [1], para el commit 6ac0aec6b0a6 ("Entrada: iforce - permite que los llamantes suministren el búfer de datos al obtener los ID de dispositivo") y comprueba que la longitud válida sea menor que los bytes a leer. Dado que iforce_get_id_packet() almacena la longitud válida al devolver 0, el llamante debe comprobar que la longitud válida sea mayor o igual que los bytes a leer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrección de fugas de solicitudes de aceptación multishot. Tener REQ_F_POLLED configurado no garantiza que la solicitud se ejecute como multishot desde la ruta de sondeo. Afortunadamente, si el código considera que se trata de un problema multishot cuando no lo es, solo puede solicitar omitir la finalización, lo que provoca la fuga de la solicitud. Use issue_flags para marcar los problemas de multipoll.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: mp2629: se corrige un posible acceso fuera de los límites de la matriz. Se agrega centinela al final de los mapas para evitar un posible acceso fuera de los límites de la matriz en el núcleo iio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: trigger: sysfs: se corrige una posible fuga de memoria en iio_sysfs_trig_init(). dev_set_name() asigna memoria para name. Esta debe liberarse cuando device_add() falla. Se llama a put_device() para liberar la referencia contenida en device_initialize(), de modo que pueda liberarse en kobject_cleanup() cuando refcount llegue a 0. La prueba de inyección de fallos puede desencadenar esto: objeto sin referencia 0xffff8e8340a7b4c0 (tamaño 32): comm "modprobe", pid 243, jiffies 4294678145 (edad 48.845s) volcado hexadecimal (primeros 32 bytes): 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............ backtrace: [<0000000074999de8>] __kmem_cache_alloc_node+0x1e9/0x360 [<00000000497fd30b>] __kmalloc_node_track_caller+0x44/0x1a0 [<000000003636c520>] kstrdup+0x2d/0x60 [<0000000032f84da2>] kobject_set_name_vargs+0x1e/0x90 [<0000000092efe493>] dev_set_name+0x4e/0x70

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: at91_adc: corrige posible pérdida de memoria en at91_adc_allocate_trigger() Si iio_trigger_register() devuelve un error, debe llamar a iio_trigger_free() para renunciar a la referencia contenida en iio_trigger_alloc(), de modo que pueda llamar a iio_trig_release() para liberar memoria cuando el recuento de referencias llegue a 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rethook: se corrige una posible fuga de memoria en rethook_alloc(). En rethook_alloc(), la variable rh no se libera ni se pasa si el manejador es NULL, lo que podría provocar una fuga de memoria. Corríjalo. [Masami: Añadir la etiqueta "rethook:" al título]. Por: Masami Hiramatsu (Google)