Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: devlink: corrige la fuga de refcount de netns en devlink_nl_cmd_reload() Mientras preparaba mi serie de parches agregando el seguimiento de refcount de netns, detecté errores en devlink_nl_cmd_reload() Algunas rutas de error olvidaron publicar un refcount en netns. Para solucionar este problema, podemos reducir el alcance de la sección get_net()/put_net() alrededor de la llamada a devlink_reload().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: oss: Limitar el tamaño del período a 16 MB Establezca el límite práctico para el tamaño del período (el desplazamiento de fragmentos en OSS) en lugar de 31 bits completos; un valor demasiado grande podría provocar el agotamiento de la memoria, ya que también asignamos búferes temporales del tamaño del período. A partir de este parche, establecimos un límite de 16 MB, que debería cubrir todos los casos de uso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrige la ejecución de inicio de nsfd (nuevamente) El commit bd5ae9288d64 ("nfsd: registre las operaciones de pernet al final, anule el registro primero") ha reabierto la ejecución de rpc_pipefs_event() contra el registro de nfsd_net_id (register_pernet_subsys( )) que se ha solucionado mediante el commit bb7ffbf29e76 ("nfsd: arreglar la ejecución de inicio de nsfd que activa BUG_ON"). Restaure el orden de Register_pernet_subsys() frente a Register_cld_notifier(). Agregue WARN_ON() para evitar una regresión futura. Información de falla: no se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000012 CPU: 8 PID: 345 Comm: mount Not tainted 5.4.144-... #1 pc: rpc_pipefs_event+0x54/0x120 [nfsd] lr: rpc_pipefs_event+0x48/ 0x120 [nfsd] Rastreo de llamadas: rpc_pipefs_event+0x54/0x120 [nfsd] blocking_notifier_call_chain rpc_fill_super get_tree_keyed rpc_fs_get_tree vfs_get_tree do_mount ksys_mount __arm64_sys_mount el0_svc_handler el0_svc

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: conjunto de cambios de intercambio gratuito en caso de fallas. Las ejecuciones de Fstests en mis VM han mostrado varios informes de kmemleak como el siguiente. objeto sin referencia 0xffff88811ae59080 (tamaño 64): comm "xfs_io", pid 12124, jiffies 4294987392 (edad 6,368 s) volcado hexadecimal (primeros 32 bytes): 00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00... ............. 90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff ................ retroceso: [<00000000ac0176d2 >] ulist_add_merge+0x60/0x150 [btrfs] [<0000000076e9f312>] set_state_bits+0x86/0xc0 [btrfs] [<0000000014fe73d6>] set_extent_bit+0x270/0x690 [btrfs] [<000000004f 675208>] set_record_extent_bits+0x19/0x20 [btrfs] [ <00000000b96137b1>] qgroup_reserve_data+0x274/0x310 [btrfs] [<0000000057e9dcbb>] btrfs_check_data_free_space+0x5c/0xa0 [btrfs] [<0000000019c4511d>] +0x1b/0xa0 [btrfs] [<000000006d37e007>] btrfs_dio_iomap_begin+0x415/0x970 [btrfs ] [<00000000fb8a74b8>] iomap_iter+0x161/0x1e0 [<0000000071dff6ff>] __iomap_dio_rw+0x1df/0x700 [<000000002567ba53>] iomap_dio_rw+0x5/0x20 [<000000 0072e555f8>] btrfs_file_write_iter+0x290/0x530 [btrfs] [<000000005eb3d845>] new_sync_write +0x106/0x180 [<000000003fb505bf>] vfs_write+0x24d/0x2f0 [<000000009bb57d37>] __x64_sys_pwrite64+0x69/0xa0 [<000000003eba3fdf>] 3/0x90 En caso de que brtfs_qgroup_reserve_data() o btrfs_delalloc_reserve_metadata() fallen, el conjunto de cambios asignado no será liberado. Entonces, en btrfs_check_data_free_space() y btrfs_delalloc_reserve_space() libera el extend_changeset asignado para deshacerte de la memoria asignada. Actualmente, el problema solo ocurre en la ruta de escritura de IO directa, pero solo después de 65b3c08606e5 ("btrfs: corrige la falla de ENOSPC al intentar escribir IO directa en el rango NOCOW"), y también en defrag_one_locked_target(). Todos los demás lugares siempre llaman a extend_changeset_free() incluso si su llamada a btrfs_delalloc_reserve_space() o btrfs_check_data_free_space() ha fallado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: aio: corrige el use-after-free debido a la falta de manejo de POLLFREE. signalfd_poll() y binder_poll() son especiales porque usan una cola de espera cuya duración es la tarea actual, en lugar de la struct archivo como es normalmente el caso. Esto está bien para bloquear encuestas, ya que una encuesta de bloqueo ocurre dentro de una tarea; sin embargo, las encuestas sin bloqueo requieren otra solución. Esta solución consiste en despejar la cola antes de liberarla, enviando una notificación POLLFREE a todos los camareros. Desafortunadamente, sólo eventpoll maneja POLLFREE. Un segundo tipo de encuesta sin bloqueo, aio poll, se agregó en el kernel v4.18 y no maneja POLLFREE. Esto permite que se produzca un use-after-free si se sondea un signalfd o un binder fd con aio poll y se libera la cola de espera. Solucione este problema haciendo que la encuesta de aio se maneje POLLFREE. Un parche de Ramji Jiyani (https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com) intentó hacer esto haciendo que aio_poll_wake() siempre completara la solicitud en línea si Se ve POLLFREE. Sin embargo, esa solución tenía dos errores. Primero, introdujo un punto muerto, ya que bloqueó incondicionalmente el contexto aio mientras mantenía el bloqueo de la cola de espera, lo que invierte el orden de bloqueo normal. En segundo lugar, no consideró que las notificaciones de POLLFREE se pierdan mientras la solicitud ha sido retirada temporalmente de la cola. El segundo problema lo resolvió mi parche anterior. Luego, este parche corrige adecuadamente el use-after-free al manejar POLLFREE sin interbloqueos. Lo hace aprovechando el hecho de que la liberación de la cola de espera tiene un retraso de RCU, similar a lo que hace eventpoll.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrige el use-after-free debido a la ejecución de delegación. Una interrupción de la delegación podría llegar tan pronto como hayamos llamado a vfs_setlease. Una interrupción de la delegación ejecuta una devolución de llamada que inmediatamente (en nfsd4_cb_recall_prepare) agrega la delegación a del_recall_lru. Si luego salimos de nfs4_set_delegation sin aplicar hash a la delegación, se liberará tan pronto como finalice la devolución de llamada, sin eliminarse nunca de del_recall_lru. Los síntomas aparecen más tarde como advertencias de use-after-free o de corrupción en la lista, generalmente en el hilo de la lavandería. Sospecho que aba2072f4523 "nfsd: otorgar delegaciones de lectura a clientes que tienen escrituras" hizo que este error fuera más fácil de corregir, pero miré hasta la versión 3.0 y me parece que ya tenía el mismo problema. Entonces no estoy seguro de dónde se introdujo el error; puede que haya estado ahí desde el principio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: códecs: wcd934x: maneja correctamente la lista de asignación de canales Actualmente, cada canal se agrega como lista a la lista de canales dai, sin embargo, existe el peligro de agregar el mismo canal a varias listas de canales dai, lo que termina corrompiendo la otra lista donde ya está agregada. Este parche garantiza que el canal esté realmente libre antes de agregarlo a la lista de canales dai y también garantiza que el canal esté en la lista antes de eliminarlo. Esta verificación faltaba anteriormente y no encontramos este problema ya que estábamos probando casos de uso muy simples con una secuencia de comandos de amixer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: garantiza que task_work se ejecute como parte de las cancelaciones. Si cancelamos con éxito un elemento de trabajo pero ese elemento de trabajo debe procesarse a través de task_work, entonces podemos estar durmiendo ininterrumpidamente en io_uring_cancel_generic() y nunca procesarlo. Por lo tanto, no avanzamos y terminamos con un aviso de sueño ininterrumpido. Mientras esté allí, corrija un comentario que debería ser IFF, no IIF.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i40e: Se corrigió la desreferencia del puntero NULL en i40e_dbg_dump_desc Al intentar volcar los descriptores VF VSI RX/TX usando debugfs, se produjo un bloqueo debido a la desreferencia del puntero NULL en i40e_dbg_dump_desc. Se agregó una verificación a i40e_dbg_dump_desc que verifica si el tipo de VSI es correcto para volcar descriptores RX/TX.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: pm80xx: No llamar a scsi_remove_host() en pm8001_alloc() Llamar a scsi_remove_host() antes de scsi_add_host() produce un bloqueo: ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000108 RIP : 0010:device_del+0x63/0x440 Seguimiento de llamadas: device_unregister+0x17/0x60 scsi_remove_host+0xee/0x2a0 pm8001_pci_probe+0x6ef/0x1b90 [pm80xx] local_pci_probe+0x3f/0x90 No podemos llamar a scsi_remove_host() en pm8001_ alloc() porque scsi_add_host() no lo ha hecho sido llamado todavía en ese momento. Árbol de llamadas a funciones: pm8001_pci_probe() | `- pm8001_pci_alloc() | | | `- pm8001_alloc() | | | `- scsi_remove_host() | `- scsi_add_host()

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: mma8452: corrección del cálculo de referencia del disparador El controlador mma8452 asigna directamente un disparador a la estructura iio_dev. El núcleo de IIO, cuando termine de usar este activador, llamará a `iio_trigger_put()` para reducir el recuento de referencias en 1. Sin el `iio_trigger_get()` coincidente en el controlador, el recuento de referencias puede llegar a 0 demasiado pronto, el activador se libera mientras aún está en se produce un uso y un use-after-free. Solucione este problema obteniendo una referencia al disparador antes de asignarlo al dispositivo IIO.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: accel: kxcjk-1013: corrija la posible pérdida de memoria en la sonda y elimínela. Cuando el tipo ACPI es ACPI_SMO8500, data->dready_trig no se configurará, la memoria asignada por iio_triggered_buffer_setup( ) no se liberará y provocará una pérdida de memoria de la siguiente manera: objeto sin referencia 0xffff888009551400 (tamaño 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (edad 83,852 s) volcado hexadecimal (primeros 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff .... .... ....... retroceso: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] ed_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [ <000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Solucionarlo eliminando la condición data->dready_trig en la sonda y eliminándola.