Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_event: Ignorar varios eventos de conexión completa Cuando uno de los tres eventos de conexión completa se recibe varias veces para el mismo identificador, el dispositivo se registra varias veces, lo que provoca corrupciones de memoria. Por lo tanto, se ignoran los eventos consecuentes para una sola conexión. El estado conn->state puede contener diferentes valores, por lo tanto, se introduce HCI_CONN_HANDLE_UNSET para identificar nuevas conexiones. Para asegurarse de que los eventos no contengan este u otro identificador no válido, se introducen HCI_CONN_HANDLE_MAX y se realizan comprobaciones. Enlace de error: https://bugzilla.kernel.org/show_bug.cgi?id=215497

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: preserve skb_end_offset() en skb_unclone_keeptruesize() syzbot encontró otra forma de activar el infame WARN_ON_ONCE(delta < len) en skb_try_coalesce() [1] Pude atribuir el problema a kfence. Cuando kfence está en acción, la siguiente afirmación ya no es verdadera: int size = xxxx; void *ptr1 = kmalloc(size, gfp); void *ptr2 = kmalloc(size, gfp); if (ptr1 && ptr2) ASSERT(ksize(ptr1) == ksize(ptr2)); Intentamos solucionar estos problemas en las confirmaciones culpadas, pero olvidamos que TCP posiblemente estaba cambiando datos después de que se haya utilizado skb_unclone_keeptruesize(), en particular desde tcp_retrans_try_collapse(). Por lo tanto, no solo debemos mantener el mismo valor de skb->truesize, también debemos asegurarnos de que TCP no llene el nuevo espacio que pskb_expand_head() pudo obtener de un addr = kmalloc(...) seguido de ksize(addr). Dividir skb_unclone_keeptruesize() en dos partes: 1) skb_unclone_keeptruesize() en línea para el caso común, cuando skb no se clona. 2) __skb_unclone_keeptruesize() fuera de línea para la 'ruta lenta'. ADVERTENCIA: CPU: 1 PID: 6490 en net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295 Módulos vinculados en: CPU: 1 PID: 6490 Comm: syz-executor161 No contaminado 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295 Código: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 fa RSP: 0018:ffffc900063af268 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000 RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003 RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000 R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8 R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155 FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: tcp_try_coalesce net/ipv4/tcp_input.c:4651 [en línea] tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630 tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914 tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025 tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947 tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719 sk_backlog_rcv include/net/sock.h:1037 [en línea] __release_sock+0x134/0x3b0 net/core/sock.c:2779 release_sock+0x54/0x1b0 net/core/sock.c:3311 sk_wait_data+0x177/0x450 net/core/sock.c:2821 tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457 tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572 inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850 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] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: CPPC: evitar el acceso fuera de los límites al analizar datos _CPC Si el campo NumEntries en el paquete de retorno _CPC es menor que 2, no intente acceder al elemento "Revisión" de ese paquete, porque es posible que no esté presente en ese momento. Enlace de error: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio: usar virtio_device_ready() en virtio_device_restore() Después de reactivar una máquina virtual suspendida, el kernel imprime el siguiente seguimiento para los controladores virtio que no llaman directamente a virtio_device_ready() en .restore: PM: suspender salir irq 22: a nadie le importó (intente arrancar con la opción "irqpoll") Seguimiento de llamada: dump_stack_lvl+0x38/0x49 dump_stack+0x10/0x12 __report_bad_irq+0x3a/0xaf note_interrupt.cold+0xb/0x60 handle_irq_event+0x71/0x80 handle_fasteoi_irq+0x95/0x1e0 __common_interrupt+0x6b/0x110 common_interrupt+0x63/0xe0 asm_common_interrupt+0x1e/0x40 ? __do_softirq+0x75/0x2f3 irq_exit_rcu+0x93/0xe0 sysvec_apic_timer_interrupt+0xac/0xd0 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch_cpu_idle+0x12/0x20 default_idle_call+0x39/0xf0 do_idle+0x1b5/0x210 cpu_startup_entry+0x20/0x30 start_secondary+0xf3/0x100 secondary_startup_64_no_verify+0xc3/0xcb controladores: [<000000008f9bac49>] vp_interrupt [<000000008f9bac49>] vp_interrupt Deshabilitando IRQ #22 Esto sucede porque no invocamos la devolución de llamada .enable_cbs en virtio_device_restore(). Esa devolución de llamada es utilizada por algunos transportes (por ejemplo, virtio-pci) para habilitar interrupciones. Vamos a solucionarlo, llamando a virtio_device_ready() como lo hacemos en virtio_dev_probe(). Esta función llama a la devolución de llamada .enable_cts y establece el bit de estado DRIVER_OK. Esta solución también evita configurar DRIVER_OK dos veces para aquellos controladores que llaman a virtio_device_ready() en .restore.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: Fix el valor menor máximo es blk_alloc_ext_minor() ida_alloc_range(..., min, max, ...) devuelve valores de min a max, ambos incluidos. Por lo tanto, NR_EXT_DEVT es un idx válido devuelto por blk_alloc_ext_minor(). Esto es un problema porque en device_add_disk(), este valor se usa en: ddev->devt = MKDEV(disk->major, disk->first_minor); y NR_EXT_DEVT es '(1 << MINORBITS)'. Por lo tanto, si 'disk->first_minor' fuera NR_EXT_DEVT, se desbordaría.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_sync: Se corrige la puesta en cola de comandos cuando HCI_UNREGISTER está configurado hci_cmd_sync_queue devolverá un error si se ha configurado el indicador HCI_UNREGISTER, ya que eso significa que se ha llamado a hci_unregister_dev, por lo que probablemente causará un uaf después del tiempo de espera, ya que se liberará el hdev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921: se corrige el bloqueo cuando falla el inicio. Si la NIC no se inicia, es posible que ya se haya programado el reset_work. Asegúrese de que el elemento de trabajo se cancele para que no tengamos un bloqueo de use-after-free en caso de que se llame a la limpieza antes de que se ejecute el elemento de trabajo. Esto corrige el bloqueo en mi apu2 x86_64 cuando la radio mt7921k no funciona. La radio sigue fallando, pero el SO no se bloquea.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ref_tracker: implementar la detección de use-after-free Siempre que se llama a ref_tracker_dir_init(), se marca la estructura ref_tracker_dir como inactiva. Pruebe el estado inactivo de ref_tracker_alloc() y ref_tracker_free() Esto debería detectar dev_put()/dev_hold() con errores que ocurren demasiado tarde en el proceso de desmantelamiento de netdevice.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/amdgpu/amdgpu_cs: se corrige la pérdida de recuento de referencias de un objeto dma_fence Este problema se produce en una ruta de error en amdgpu_cs_fence_to_handle_ioctl(). Cuando `info->in.what` cae en el caso predeterminado, la función simplemente devuelve -EINVAL, olvidando disminuir el recuento de referencias de un objeto dma_fence, que es aumentado anteriormente por amdgpu_cs_get_fence(). Esto puede provocar fugas de recuento de referencias. Arréglelo disminuyendo el recuento de referencias de un objeto específico antes de devolver el código de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corregir pérdida de memoria [por qué] Se necesita la liberación de recursos en la ruta de manejo de errores para evitar pérdidas de memoria. [cómo] Solucione esto agregando kfree en la ruta de manejo de errores.