Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: elimina solicitudes de xarray durante las solicitudes de vaciado Incluso con CACHEFILES_DEAD configurado, aún podemos leer las solicitudes, por lo que en la siguiente concurrencia la solicitud se puede usar después de que se haya liberado: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------- --------- Cachefiles_ondemand_init_object Cachefiles_ondemand_send_req req_a = kzalloc (sizeof (*req) + data_len) Wait_for_completion (& req_a-> ded) gratis (req_a ) xa_lock(&cache->reqs); cachefiles_ondemand_select_req req->msg.opcode != CACHEFILES_OP_READ // ¡¡¡requiere use-after-free !!! xa_unlock(&cache->reqs); xa_destroy(&cache->reqs) Por lo tanto, elimine las solicitudes de cache->reqs cuando las vacíe para evitar acceder a las solicitudes liberadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Evite que test/set_bit() opere en memoria no asignada. Existe un posible acceso fuera de los límites cuando se usa test_bit() en una sola palabra. Las funciones test_bit() y set_bit() operan con valores largos y, al probar o configurar una sola palabra, pueden exceder el límite de la palabra. KASAN detecta este problema y produce un volcado: ERROR: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/ bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Escritura de tamaño 8 en la dirección ffff8881d26e3c60 mediante tarea kworker/u1536:2/2965 Para obtener el registro completo, consulte [1]. Realice la asignación al menos del tamaño de sizeof(unsigned long) para que set_bit() y test_bit() tengan suficiente espacio para operaciones de lectura/escritura sin sobrescribir la memoria no asignada. [1] Enlace: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ionic: corrige el pánico del kernel en la acción XDP_TX En la ruta XDP_TX, el controlador ionic envía un paquete a la ruta TX con la página rx y la dirección dma correspondiente. Una vez finalizada la transmisión, ionic_tx_clean() libera esa página. Pero el búfer de anillo RX no se restablece a NULL. Por lo tanto, utiliza una página liberada, lo que provoca pánico en el kernel. ERROR: no se puede manejar el error de página para la dirección: ffff8881576c110c PGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060 Ups: Ups: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI CPU: 1 PID: 25 Comunicaciones: ksoftirqd/1 No contaminado 6.9. 0+ #11 Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 01/11/2021 RIP: 0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f Código: 00 53 41 55 41 56 41 57 b8 01 0 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8 RSP: 0018:ffff888104e6fa28 EFLAGS: 00010283 RAX: 0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002 RDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e RBP: ffff888104e6fa88 R08: 0000000000000000 R09 : ffffed1027a04a23 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8 R13: ffff8881589f800f R14: ffff8881576c1100 R15: 0001576c1100 FS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0 PKRU: 55555554 Seguimiento de llamadas: ? __morir+0x20/0x70 ? page_fault_oops+0x254/0x790? __pfx_page_fault_oops+0x10/0x10? __pfx_is_prefetch.constprop.0+0x10/0x10 ? search_bpf_extables+0x165/0x260? fixup_exception+0x4a/0x970? exc_page_fault+0xcb/0xe0? asm_exc_page_fault+0x22/0x30? 0xffffffffc0051f64? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f? do_raw_spin_unlock+0x54/0x220 ionic_rx_service+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? ionic_tx_clean+0x29b/0xc60 [iónico 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_tx_clean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? ionic_tx_cq_service+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] ionic_cq_service+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] x_napi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864] __napi_poll.constprop.0+0xa0/0x440 net_rx_action+0x7e7/0xc30 ? __pfx_net_rx_action+0x10/0x10

Securepoint UTM anterior a 12.6.5 maneja mal los códigos OTP.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: greybus: corrigió el error de use-after-free en gb_interface_release debido a la condición de ejecución. En gb_interface_create, &intf->mode_switch_completion está vinculado con gb_interface_mode_switch_work. Luego lo iniciará gb_interface_request_mode_switch. Aquí está el código relevante. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } Si llamamos a gb_interface_release para realizar la limpieza, es posible que haya un trabajo sin terminar. Esta función llamará a kfree para liberar el objeto "intf". Sin embargo, si gb_interface_mode_switch_work está programado para ejecutarse después de kfree, puede causar un error de use-after-free ya que gb_interface_mode_switch_work usará el objeto "intf". El posible flujo de ejecución que puede provocar el problema es el siguiente: CPU0 CPU1 | gb_interface_create | gb_interface_request_mode_switch gb_interface_release | kfree(intf) (gratis) | | gb_interface_mode_switch_work | mutex_lock(&intf->mutex) (uso) Solucionarlo cancelando el trabajo antes de kfree.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/shmem-helper: corrige BUG_ON() en mmap(PROT_WRITE, MAP_PRIVATE) La falta de verificación para el mapeo de copia en escritura (COW) en drm_gem_shmem_mmap permite a los usuarios llamar a mmap con Los indicadores PROT_WRITE y MAP_PRIVATE causan un pánico en el kernel debido a BUG_ON en vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Devuelva -EINVAL temprano si se detecta el mapeo COW. Este error afecta a todos los controladores drm que utilizan ayudantes shmem predeterminados. Se puede reproducir con este sencillo ejemplo: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0;

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mst: corrige la desreferencia del puntero NULL en drm_dp_add_payload_part2 [Por qué] Commit: - commit 5aa1dfcdf0a4 ("drm/mst: refactorizar el flujo para la asignación/eliminación de carga") sobrescribe accidentalmente el commit - commit 54d217406afe ("drm: use mgr->dev en drm_dbg_kms en drm_dp_add_payload_part2") que causa regresión. [Cómo] Recupere la corrección NULL original y elimine el parámetro de entrada innecesario 'estado' para drm_dp_add_payload_part2(). (cereza escogida del commit 4545614c1d8da603e57b60dd66224d81b6ffc305)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vmci: evita fugas especulativas sanitizando el evento en event_deliver(). Coverity detectó que event_msg está controlado por el espacio de usuario, event_msg->event_data.event se pasa a event_deliver() y se usa como un índice sin sanitización. Este cambio garantiza que el índice de eventos esté sanitizado para mitigar cualquier posibilidad de fuga de información especulativa. Este error fue descubierto y resuelto utilizando Coverity Static Analysis Security Testing (SAST) por Synopsys, Inc. Solo se prueba la compilación, no hay acceso al hardware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: core: sincronizar Actually_probe() y dev_uevent() Sincronizar el uso dev->driver en Actually_probe() y dev_uevent(). Estos pueden ejecutarse en diferentes subprocesos, lo que puede resultar en la siguiente condición de ejecución para dev->desinicialización del controlador: Subproceso n.° 1: ========== reality_probe() { ... probe_failed: ... device_unbind_cleanup( dev) { ... dev->controlador = NULL; // <= La sonda fallida establece dev->driver en NULL ... } ... } Hilo #2: ========== dev_uevent() { ... if (dev->driver) / / Si dev->driver recibe un valor NULL desde reality_probe() de ahora en adelante, // después de la verificación anterior, el sistema falla add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }realmente_probe() ya tiene el bloqueo. Entonces no es necesario hacer nada allí. A menudo también se llama a dev_uevent() con el bloqueo mantenido. Pero no siempre. Lo que implica que no podemos agregar ningún bloqueo en el propio dev_uevent(). Así que arregle esta ejecución agregando el candado al camino no protegido. Esta es la ruta donde se observa la ejecución anterior: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Agregar bloqueo aquí dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/ 0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Casos similares son reportados por syzkaller en https://syzkaller.appspot.com/bug?extid =ffa8143439596313a85a Pero estos se refieren a la *inicialización* de dev->driver dev->driver = drv; Como esto cambia dev->driver a no NULL, estos informes pueden considerarse falsos positivos (aunque esté commit también debería "solucionarlos"). El mismo problema se informó y se intentó solucionar en 2015 en https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/ ya.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_inner: valida meta y payload obligatorias. Comprueba los atributos de enlace de red obligatorios en el payload y la metaexpresión cuando se utilizan incrustados desde la expresión interna; de lo contrario, es posible desreferenciar el puntero NULL desde el espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/komeda: verifique el puntero con valor de error komeda_pipeline_get_state() puede devolver un puntero con valor de error, por lo tanto, verifique el puntero en busca de valores negativos o nulos antes de eliminar la referencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: liquidio: ajusta una ruta de manejo de puntero NULL en lio_vf_rep_copy_packet En lio_vf_rep_copy_packet() pg_info->page se compara con un valor NULL, pero luego se pasa incondicionalmente a skb_add_rx_frag() lo cual parece extraño y podría provocar una desreferencia del puntero nulo. El seguimiento de llamadas de lio_vf_rep_copy_packet() se ve así: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...buscar en la lista de despacho... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *rec v_info, ...) En este camino hay No hay ningún código que establezca pg_info->page en NULL. Por lo tanto, esta verificación parece innecesaria y no resuelve el problema potencial. Pero supongo que el autor tenía motivos para agregar un cheque y yo no tengo esa tarjeta y no puedo hacer una prueba real. Además, el código de la función liquidio_push_packet() en liquidio/lio_core.c hace exactamente lo mismo. En base a esto, considero la solución de compromiso más aceptable para ajustar este problema moviendo skb_add_rx_frag() al alcance condicional. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.