Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: corrección de la desreferencia de puntero nulo en hci_sync_conn_complete_evt Este evento solo se especifica para los tipos de enlace SCO y eSCO. Al recibir un HCI_Synchronous_Connection_Complete para una BDADDR de una conexión LE existente, un tipo de enlace LE y un estado que activa el segundo caso del procesamiento de paquetes, se produce una desreferencia de puntero NULL, ya que conn->link es NULL.

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: dsa: felix: se corrige la posible desreferencia de puntero NULL. Como es posible que falle la asignación, kzalloc() puede devolver un puntero NULL. Por lo tanto, es mejor comprobar el 'sgi' para evitar la desreferencia de puntero NULL.

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: se corrige la pérdida de memoria del uid en el registro de archivos. Cuando no hay archivos para que __io_sqe_files_scm() procese en el rango, liberará todo y regresará. Sin embargo, se olvida de poner el uid.

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: watch_queue: liberar la matriz de páginas cuando se desmantela watch_queue. el commit 7ea1a0124b6d ("watch_queue: liberar el mapa de bits de asignación cuando se desmantela watch_queue") se hizo cargo del mapa de bits, pero no de la matriz de páginas. ERROR: pérdida de memoria objeto no referenciado 0xffff88810d9bc140 (tamaño 32): comm "syz-executor335", pid 3603, jiffies 4294946994 (edad 12.840s) volcado hexadecimal (primeros 32 bytes): 40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: kmalloc_array include/linux/slab.h:621 [en línea] kcalloc include/linux/slab.h:652 [en línea] watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251 pipe_ioctl+0x82/0x140 fs/pipe.c:632 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:874 [en línea] __se_sys_ioctl fs/ioctl.c:860 [en línea] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [en línea]

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.