Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethtool: no realiza operaciones en dispositivos de red que se están dando de baja. Hay un breve período entre que un dispositivo de red comienza a darse de baja y cuando realmente desaparece. En ese período aún se podrían realizar operaciones de ethtool, lo que podría terminar en comportamientos no deseados o indefinidos[1]. No permita operaciones de ethtool después de que un dispositivo de red inicie su cancelación del registro. Este parche apunta a la parte netlink ya que la parte ioctl no se ve afectada: se toma la referencia al dispositivo de red y la operación se ejecuta dentro de una sección de bloqueo rtnl y el dispositivo de red no se encontrará después de cancelar el registro. [1] Por ejemplo, agregar colas de Tx después de cancelar el registro termina en excepciones de puntero NULL y UaF, como: ERROR: KASAN: use-after-free en kobject_get+0x14/0x90 Lectura de tamaño 1 en la dirección ffff88801961248c mediante la tarea ethtool/755 CPU : 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014 Seguimiento de llamadas: dump_stack_lvl+0x57/0x72 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b kobject_get+0x14/0x90 kobject_add_internal+0x3d1/0x450 kobject_init_and_add+0xba/0xf0 netdev_queue_update_kobjects+0xcf/0x200 netif_set_real_num_tx_queues+0xb4/0x310 veth_set_channels+0x1c3/0x550 ethnl_set_channels+0x524/ 0x610

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: corrige la posible deref del puntero NULL en nfc_genl_dump_ses_done La devolución de llamada de netlink done() nfc_genl_dump_ses_done() debe verificar si el argumento recibido no es NULL, porque su asignación podría fallar antes en dumpit() (nfc_genl_dump_ses()).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: m_can: m_can_read_fifo: corrige la pérdida de memoria en la rama de error En m_can_read_fifo(), si la segunda llamada a m_can_fifo_read() falla, la función salta a la etiqueta out_fail y regresa sin llamar m_can_receive_skb(). Esto significa que el skb previamente asignado por alloc_can_skb() no se libera. En otras palabras, se trata de una pérdida de memoria. Este parche agrega una etiqueta goto para destruir el skb si ocurre un error. Se encontró un problema con GCC -fanalyzer; siga el enlace a continuación para obtener más detalles.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige el proceso re-sucio de los nodos de registro de árbol Hay un informe de una transacción cancelada de -EAGAIN with the following script. #!/bin/sh for d in sda sdb; do mkfs.btrfs -d single -m single -f /dev/\${d} done mount /dev/sda /mnt/test mount /dev/sdb /mnt/scratch for dir in test scratch; do echo 3 >/proc/sys/vm/drop_caches fio --directory=/mnt/\${dir} --name=fio.\${dir} --rw=read --size=50G --bs=64m \ --numjobs=$(nproc) --time_based --ramp_time=5 --runtime=480 \ --group_reporting |& tee /dev/shm/fio.\${dir} echo 3 >/proc/sys/vm/drop_caches done for d in sda sdb; do umount /dev/\${d} done The stack trace is shown in below. [3310.967991] BTRFS: error (device sda) in btrfs_commit_transaction:2341: errno=-11 unknown (Error while writing out transaction) [3310.968060] BTRFS info (device sda): forced readonly [3310.968064] BTRFS warning (device sda): Skipping commit of aborted transaction. [3310.968065] ------------[ cut here ]------------ [3310.968066] BTRFS: Transaction aborted (error -11) [3310.968074] WARNING: CPU: 14 PID: 1684 at fs/btrfs/transaction.c:1946 btrfs_commit_transaction.cold+0x209/0x2c8 [3310.968131] CPU: 14 PID: 1684 Comm: fio Not tainted 5.14.10-300.fc35.x86_64 #1 [3310.968135] Hardware name: DIAWAY Tartu/Tartu, BIOS V2.01.B10 04/08/2021 [3310.968137] RIP: 0010:btrfs_commit_transaction.cold+0x209/0x2c8 [3310.968144] RSP: 0018:ffffb284ce393e10 EFLAGS: 00010282 [3310.968147] RAX: 0000000000000026 RBX: ffff973f147b0f60 RCX: 0000000000000027 [3310.968149] RDX: ffff974ecf098a08 RSI: 0000000000000001 RDI: ffff974ecf098a00 [3310.968150] RBP: ffff973f147b0f08 R08: 0000000000000000 R09: ffffb284ce393c48 [3310.968151] R10: ffffb284ce393c40 R11: ffffffff84f47468 R12: ffff973f101bfc00 [3310.968153] R13: ffff971f20cf2000 R14: 00000000fffffff5 R15: ffff973f147b0e58 [3310.968154] FS: 00007efe65468740(0000) GS:ffff974ecf080000(0000) knlGS:0000000000000000 [3310.968157] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3310.968158] CR2: 000055691bcbe260 CR3: 000000105cfa4001 CR4: 0000000000770ee0 [3310.968160] PKRU: 55555554 [3310.968161] Call Trace: [3310.968167] ? dput+0xd4/0x300 [3310.968174] btrfs_sync_file+0x3f1/0x490 [3310.968180] __x64_sys_fsync+0x33/0x60 [3310.968185] do_syscall_64+0x3b/0x90 [3310.968190] entry_SYSCALL_64_after_hwframe+0x44/0xae [3310.968194] RIP: 0033:0x7efe6557329b [3310.968200] RSP: 002b:00007ffe0236ebc0 EFLAGS: 00000293 ORIG_RAX: 000000000000004a [3310.968203] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007efe6557329b [3310.968204] RDX: 0000000000000000 RSI: 00007efe58d77010 RDI: 0000000000000006 [3310.968205] RBP: 0000000004000000 R08: 0000000000000000 R09: 00007efe58d77010 [3310.968207] R10: 0000000016cacc0c R11: 0000000000000293 R12: 00007efe5ce95980 [3310.968208] R13: 0000000000000000 R14: 00007efe6447c790 R15: 0000000c80000000 [3310.968212] ---[ end trace 1a346f4d3c0d96ba ]--- [3310.968214] BTRFS: error (device sda) in cleanup_transaction:1946: errno=-11 unknown. El aborto se produce debido a un agujero de escritura mientras se escriben los nodos del árbol liberado de un árbol de registro de árbol. Para btrfs zonificados, volvemos a ensuciar un nodo de árbol liberado para garantizar que btrfs pueda escribir la región y no deje un agujero al escribir en un dispositivo zonificado. El código actual no puede volver a ensuciar un nodo cuando la profundidad del árbol de registro es mayor o igual a 2. Eso conduce a una transacción abortada con -EAGAIN. Solucione el problema volviendo a ensuciar adecuadamente un nodo al subir al árbol.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: oss: corrige tamaños de período/búfer negativos El cálculo del tamaño del período en la capa OSS puede recibir un valor negativo como error, pero el código allí asume solo los valores positivos y manejarlos con size_t. Debido a esto, es posible que se pase un valor demasiado grande a las capas inferiores. Este parche cambia el código para manejar con ssize_t y agrega las comprobaciones de errores adecuadas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: fq_pie: previene el problema de desmantelamiento Por alguna razón, fq_pie_destroy() no copió el código de trabajo de pie_destroy() y otras qdiscs, causando así un error difícil de alcanzar. Antes de llamar a del_timer_sync(&q->adapt_timer), debemos asegurarnos de que el temporizador no se rearme solo. rcu: INFO: rcu_preempt se bloqueó automáticamente en la CPU rcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579 (t=10501 jiffies g=13085 q=3989) NMI backtrace for cpu 0 CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343 print_cpu_stall kernel/rcu/tree_stall.h:627 [inline] check_cpu_stall kernel/rcu/tree_stall.h:711 [inline] rcu_pending kernel/rcu/tree.c:3878 [inline] rcu_sched_clock_irq.cold+0x9d/0x746 kernel/rcu/tree.c:2597 update_process_times+0x16d/0x200 kernel/time/timer.c:1785 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226 tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428 __run_hrtimer kernel/time/hrtimer.c:1685 [inline] __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749 hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline] __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103 sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638 RIP: 0010:write_comp_data kernel/kcov.c:221 [inline] RIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1d/0x80 kernel/kcov.c:273 Code: 54 c8 20 48 89 10 c3 66 0f 1f 44 00 00 53 41 89 fb 41 89 f1 bf 03 00 00 00 65 48 8b 0c 25 40 70 02 00 48 89 ce 4c 8b 54 24 08 4e f7 ff ff 84 c0 74 51 48 8b 81 88 15 00 00 44 8b 81 84 15 00 RSP: 0018:ffffc90000d27b28 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888064bf1bf0 RCX: ffff888011928000 RDX: ffff888011928000 RSI: ffff888011928000 RDI: 0000000000000003 RBP: ffff888064bf1c28 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff875d8295 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880783dd300 R14: 0000000000000000 R15: 0000000000000000 pie_calculate_probability+0x405/0x7c0 net/sched/sch_pie.c:418 fq_pie_timer+0x170/0x2a0 net/sched/sch_fq_pie.c:383 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 expire_timers kernel/time/timer.c:1466 [inline] __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734 __run_timers kernel/time/timer.c:1715 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:dsa:felix: Reparar pérdida de memoria en felix_setup_mmio_filtering Evitar una pérdida de memoria si no hay un puerto de CPU definido. Direcciones-Coverity-ID: 1492897 ("Fuga de recursos") Direcciones-Coverity-ID: 1492899 ("Fuga de recursos")

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: seg6: corrige el iif en el bloque de control del socket IPv6 Cuando se recibe un paquete IPv4, ip_rcv_core(...) establece el índice de la interfaz de recepción en el bloque de control del socket IPv4 (v5 .16-rc4, net/ipv4/ip_input.c línea 510): IPCB(skb)->iif = skb->skb_iif; Si ese paquete IPv4 debe encapsularse en un encabezado IPv6+SRH externo, seg6_do_srh_encap(...) realiza la encapsulación requerida. En este caso, la función seg6_do_srh_encap borra el bloque de control del socket IPv6 (v5.16-rc4 net/ipv6/seg6_iptunnel.c línea 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); El memset(...) se introdujo en El commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) en la encapsulación SRH ip4ip6") hace mucho tiempo (29 de enero de 2019). Dado que el bloque de control del socket IPv6 y el bloque de control del socket IPv4 comparten la misma área de memoria (skb->cb), la información del índice de la interfaz de recepción se pierde (IP6CB(skb)->iif se establece en cero). Como efecto secundario, esa condición desencadena una desreferencia del puntero NULL si se aplica el commit 0857d6f8c759 ("ipv6: al reenviar estadísticas de recuento de rx en el netdev original"). Para solucionar ese problema, configuramos IP6CB(skb)->iif con el índice de la interfaz de recepción una vez más.

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: 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