Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: gamecube: Se corrige la pérdida de recuento de referencias en gamecube_rtc_read_offset_from_sram La función of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando termine. Agregue el of_node_put() faltante para liberar el recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: suprimir una queja del kernel en qla_create_qpair() [ 12.323788] ERROR: uso de smp_processor_id() en código preemptible [00000000]: systemd-udevd/1020 [ 12.332297] el llamador es qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: GI --------- --- 5.14.0-29.el9.x86_64 #1 [ 12.348827] Nombre del hardware: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 22/05/2018 [ 12.356356] Seguimiento de llamadas: [ 12.358821] dump_stack_lvl+0x34/0x44 [ 12.362514] check_preemption_disabled+0xd9/0xe0 [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40 [ 12.384284] local_pci_probe+0x42/0x80 [ 12.390162] ? pci_match_device+0xd7/0x110 [ 12.396366] pci_device_probe+0xfd/0x1b0 [ 12.402372] really_probe+0x1e7/0x3e0 [ 12.408114] __driver_probe_device+0xfe/0x180 [ 12.414544] driver_probe_device+0x1e/0x90 [ 12.420685] __driver_attach+0xc0/0x1c0 [ 12.426536] ? __device_attach_driver+0xe0/0xe0 [ 12.433061] ? __device_attach_driver+0xe0/0xe0 [ 12.439538] bus_for_each_dev+0x78/0xc0 [ 12.445294] bus_add_driver+0x12b/0x1e0 [ 12.451021] driver_register+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx] [ 12.468776] do_one_initcall+0x44/0x200 [ 12.474401] ? load_module+0xad3/0xba0 [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410 [ 12.486268] do_init_module+0x5c/0x280 [ 12.491730] __do_sys_init_module+0x12e/0x1b0 [ 12.497785] do_syscall_64+0x3b/0x90 [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: se corrige el pánico en la IRQ de invitado fuera de los límites Como guest_irq proviene de la llamada API KVM_IRQFD, puede provocar un bloqueo en svm_update_pi_irte() debido a fuera de los límites: crash> bt PID: 22218 TAREA: ffff951a6ad74980 CPU: 73 COMANDO: "vcpu8" #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397 #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end en ffffffff85623c0d #4 [ffffb1ba6707fb90] no_context en ffffffff856692c9 #5 [ffffb1ba6707fbf8] exc_page_fault en ffffffff85f95b51 #6 [ffffb1ba6707fc50] asm_exc_page_fault en ffffffff86000ace [excepción RIP: svm_update_pi_irte+227] RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086 RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001 RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8 RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200 R10: ffffffffffffffcf R11: 0000000000000001 R12: 00000000000000001 R13: 0000000000000001 R14: ffffffffffffffcf R15: 0000000000000005f ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb1ba6707fdb8] actualización de enrutamiento irq kvm en ffffffffc09f19a1 [kvm] #8 [ffffb1ba6707fde0] enrutamiento irq kvm_establecido en ffffffffc09f2133 [kvm] #9 [ffffb1ba6707fe18] kvm_vm_ioctl en ffffffffc09ef544 [kvm] RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020 RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0 R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0 R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b Vmx ha solucionado esto en el commit 3a8b0677fc61 (KVM: VMX: No BUG() en IRQ de invitado fuera de los límites), por lo que podemos simplemente copiar la fuente de allí para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Fix scheduling while atomic El controlador realiza una llamada a la capa intermedia (fc_remote_port_delete) que puede poner el hilo en suspensión. El hilo que origina la llamada está en un contexto de interrupción. La combinación de los dos desencadena un bloqueo. Programe la llamada en un contexto sin interrupciones donde sea más seguro. núcleo: ERROR: programación mientras atómico: swapper/7/0/0x00010000 núcleo: Seguimiento de llamadas: núcleo: kernel: dump_stack+0x66/0x81 kernel: __schedule_bug.cold.90+0x5/0x1d kernel: __schedule+0x7af/0x960 kernel: schedule+0x28/0x80 kernel: schedule_timeout+0x26d/0x3b0 kernel: wait_for_completion+0xb4/0x140 kernel: ? wake_up_q+0x70/0x70 kernel: __wait_rcu_gp+0x12c/0x160 kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod] kernel: synchronize_sched+0x6c/0x80 kernel: ? call_rcu_bh+0x20/0x20 kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10 kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod] kernel: starget_for_each_device+0x85/0xb0 [scsi_mod] kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod] kernel: scsi_init_io+0x388/0x3d0 [scsi_mod] kernel: device_for_each_child+0x54/0x90 kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc] kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx] kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx] kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx] kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx] kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx] kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx] kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx] kernel: __handle_irq_event_percpu+0x40/0x180 kernel: handle_irq_event_percpu+0x30/0x80 kernel: handle_irq_event+0x36/0x60

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Reparar acceso prematuro a hardware después de un error PCI Después de que se haya detectado y recuperado un error PCI recuperable, el controlador qla necesita verificar si la condición de error aún persiste y/o esperar a que el SO dé la señal de reanudación. 8 sep 22:26:03 kernel localhost: ADVERTENCIA: CPU: 9 PID: 124606 en qla_tmpl.c:440 qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] 8 sep 22:26:03 kernel localhost: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] 8 sep 22:26:03 kernel localhost: Rastreo de llamada: 8 sep 22:26:03 kernel localhost: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx] 8 sep 22:26:03 núcleo localhost: ? qla27xx_execute_fwdt_template+0x12a/0x160 [qla2xxx] 8 sep 22:26:03 núcleo localhost: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx] 8 sep 22:26:03 núcleo localhost: ? qla2xxx_pci_mmio_enabled+0xfb/0x120 [qla2xxx] 8 sep 22:26:03 núcleo localhost: ? report_mmio_enabled+0x44/0x80 8 sep 22:26:03 núcleo localhost: ? report_slot_reset+0x80/0x80 8 sep 22:26:03 kernel localhost: ? pci_walk_bus+0x70/0x90 8 sep 22:26:03 kernel localhost: ? aer_dev_correctable_show+0xc0/0xc0 8 sep 22:26:03 kernel localhost: ? pcie_do_recovery+0x1bb/0x240 8 sep 22:26:03 kernel localhost: ? aer_recover_work_func+0xaa/0xd0 8 sep 22:26:03 kernel localhost: ? process_one_work+0x1a7/0x360 .. 8 sep 22:26:03 kernel localhost: qla2xxx [0000:42:00.2]-8041:22: se detectó una desconexión de PCI. 8 sep 22:26:03 kernel localhost: qla2xxx [0000:42:00.2]-107ff:22: qla27xx_fwdt_entry_t262: se produjo un error al volcar la memoria RAM de la placa base. Área 5h inicio 198013h fin 198013h 8 sep 22:26:03 kernel localhost: qla2xxx [0000:42:00.2]-107ff:22: No se puede capturar el volcado de FW 8 sep 22:26:03 kernel localhost: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0, esperó 5221 msecs 8 sep 22:26:03 kernel localhost: qla2xxx [0000:42:00.2]-680d:22: mmio habilitado regresando. 8 de septiembre 22:26:03 kernel localhost: qla2xxx [0000:42:00.2]-d04c:22: Tiempo de espera del comando MBX para cmd 0, iocontrol=ffffffff jiffies=10140f2e5 mb[0-3]=[0xffff 0xffff 0xffff 0xffff]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Se soluciona el inicio del temporizador de llamadas con la destrucción de llamadas La estructura rxrpc_call tiene un temporizador que se utiliza para gestionar varios eventos temporizados relacionados con una llamada. Este temporizador puede iniciarse desde las rutinas de entrada de paquetes que se ejecutan en modo softirq con solo el bloqueo de lectura RCU mantenido. Desafortunadamente, debido a que solo se mantiene el bloqueo de lectura RCU, y no se toma ninguna referencia ni ningún otro bloqueo, la llamada puede comenzar a destruirse al mismo tiempo que llega un paquete dirigido a esa llamada. Esto hace que el temporizador, que ya estaba detenido, se reinicie. Más tarde, el código de despacho del temporizador puede fallar si el temporizador se desasignó primero. Solucione esto intentando tomar una referencia en la estructura rxrpc_call y, si tiene éxito, pasando esa referencia al temporizador. Si el temporizador ya se estaba ejecutando, la referencia se descarta. La rutina de finalización del temporizador puede pasar la referencia al elemento de trabajo de la llamada cuando lo pone en cola. Si el temporizador o el elemento de trabajo ya estaban en cola o en ejecución, la referencia adicional se descarta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: mcba_usb: comprobar correctamente el tipo de endpoint Syzbot informó de una advertencia en usb_submit_urb() que es causada por un tipo de endpoint incorrecto. Deberíamos comprobar que en el endpoint esté realmente presente para evitar esta advertencia. Las tuberías encontradas ahora se guardan en la estructura mcba_priv y el código las usa directamente en lugar de crear tuberías en su lugar. Registro de errores: | usb 5-1: BOGUS urb xfer, pipe 3 != type 1 | ADVERTENCIA: CPU: 1 PID: 49 en drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | Módulos vinculados en: | CPU: 1 PID: 49 Comm: kworker/1:2 No contaminado 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0 | Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 | Cola de trabajo: usb_hub_wq hub_event | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | ... | Seguimiento de llamadas: | | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [en línea] | mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858 | usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 | call_driver_probe drivers/base/dd.c:517 [en línea]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: XArray: Arreglar xas_create_range() cuando hay una entrada de orden múltiple presente Si ya hay una entrada presente que es de orden >= XA_CHUNK_SHIFT cuando llamamos a xas_create_range(), xas_create_range() malinterpretará esa entrada como un nodo y desreferenciará xa_node->parent, generalmente provocando un bloqueo que se parece a esto: error de protección general, probablemente para una dirección no canónica 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000008-0x000000000000000f] CPU: 0 PID: 32 Comm: khugepaged No contaminado 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0 RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline] RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725 Es deterministamente reproducible una vez que sabes cuál es el problema, pero producirlo en un núcleo en vivo requiere que khugepaged alcance una ejecución. Si bien el problema ha estado presente desde que se introdujo xas_create_range(), no conozco una forma de alcanzarlo antes de que la caché de páginas se convirtiera para usar entradas de índice múltiple.

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

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