Instituto Nacional de ciberseguridad. Sección Incibe

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.



Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

  • Vulnerabilidad en Mia Technology Inc. M?A-MED (CVE-2023-6515)
    Severidad: Pendiente de análisis
    Fecha de publicación: 08/02/2024
    Fecha de última actualización: 18/03/2024
    Vulnerabilidad de omisión de autorización a través de clave controlada por el usuario en Mia Technology Inc. M?A-MED permite el abuso de autenticación. Este problema afecta a M?A-MED: versiones anteriores a 1.0.7.
  • Vulnerabilidad en Mia Technology Inc. M?A-MED (CVE-2023-6517)
    Severidad: Pendiente de análisis
    Fecha de publicación: 08/02/2024
    Fecha de última actualización: 18/03/2024
    Exposición de información confidencial debido a una vulnerabilidad de políticas incompatibles en Mia Technology Inc. M?A-MED permite recopilar datos proporcionados por los usuarios. Este problema afecta a M?A-MED: antes de 1.0.7.
  • Vulnerabilidad en Mia Technology Inc. M?A-MED (CVE-2023-6518)
    Severidad: Pendiente de análisis
    Fecha de publicación: 08/02/2024
    Fecha de última actualización: 18/03/2024
    Vulnerabilidad de almacenamiento de texto plano de una contraseña en Mia Technology Inc. M?A-MED permite leer cadenas confidenciales dentro de un ejecutable. Este problema afecta a M?A-MED: versiones anteriores a 1.0.7.
  • Vulnerabilidad en Mia Technology Inc. M?A-MED (CVE-2023-6519)
    Severidad: Pendiente de análisis
    Fecha de publicación: 08/02/2024
    Fecha de última actualización: 18/03/2024
    Vulnerabilidad de exposición de elemento de datos a sesión incorrecta en Mia Technology Inc. M?A-MED permite leer cadenas confidenciales dentro de un ejecutable. Este problema afecta a M?A-MED: versiones anteriores a 1.0.7.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52448)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: Se corrigió la desreferencia del puntero NULL del kernel en gfs2_rgrp_dump Syzkaller ha informado una desreferencia del puntero NULL al acceder a rgd->rd_rgl en gfs2_rgrp_dump(). Esto puede suceder cuando la creación de rgd->rd_gl falla en read_rindex_entry(). Agregue una verificación de puntero NULL en gfs2_rgrp_dump() para evitarlo.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52449)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: corrige la desreferencia del puntero NULL de Gluebi causada por el notificador ftl. Si se cargan tanto ftl.ko como pegamentobi.ko, el notificador de ftl activa la desreferencia del puntero NULL al intentar acceder a 'gluebi-. >desc' en pegamentobi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all pegamentobi_notify nb->notifier_call() pegamentobi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std pegamentobi_read mtd->read() pegamentobi->desc - NULL Información detallada de reproducción disponible en el enlace [1], en el caso normal, obtenga pegamentobi->desc en pegamentobi_get_device() y acceda a pegamentobi->desc en pegamentobi_read(). Sin embargo, pegamentobi_get_device() no se ejecuta de antemano en el proceso ftl_add_mtd(), lo que conduce a la desreferencia del puntero NULL. La solución para el módulo pegamentobi es ejecutar jffs2 en el volumen UBI sin considerar trabajar con ftl o mtdblock [2]. Por lo tanto, este problema se puede evitar evitando que pegamentobi cree el dispositivo mtdblock después de crear la partición mtd del tipo MTD_UBIVOLUME.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52450)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/x86/intel/uncore: solucione el problema de desreferencia del puntero NULL en upi_fill_topology(). Obtenga la identificación del socket lógico en lugar de la identificación física en discover_upi_topology() para evitar el acceso fuera de límites en 'upi = &tipo->topología[nid][idx];' línea que conduce a la desreferencia del puntero NULL en upi_fill_topology()
  • Vulnerabilidad en kernel de Linux, (CVE-2023-52451)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/pseries/memhp: corrige el acceso más allá del final de la matriz drmem dlpar_memory_remove_by_index() puede acceder más allá de los límites de la matriz lmb drmem cuando la búsqueda de LMB no coincide con una entrada con el valor dado Índice de la República Democrática del Congo. Cuando la búsqueda falla, el cursor queda apuntando a &drmem_info->lmbs[drmem_info->n_lmbs], que es un elemento después de la última entrada válida en la matriz. El mensaje de depuración al final de la función elimina la referencia a este puntero: pr_debug("Error al eliminar memoria en caliente en %llx\n", lmb->base_addr); Esto se encontró mediante inspección y se confirmó con KASAN: pseries-hotplug-mem: Intentando eliminar LMB en caliente, índice drc 1234 ========================== ========================================== ERROR: KASAN: losa- fuera de límites en dlpar_memory+0x298/0x1658 Lectura de tamaño 8 en la dirección c000000364e97fd0 por tarea bash/949 dump_stack_lvl+0xa4/0xfc (no confiable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/ 0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog +0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Asignado por tarea 1: kasan_save_stack +0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one _initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+ 0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c La dirección con errores pertenece al objeto en c000000364e80000 que pertenece al caché kmalloc-128k de tamaño 131072 La dirección con errores se encuentra 0 bytes a la derecha de la región asignada de 98256 bytes [c000000364e80000, c0 00000364e97fd0) = ==================================================== =============== pseries-hotplug-mem: No se pudo eliminar la memoria en caliente en 0 Registre las búsquedas fallidas con un mensaje separado y elimine la referencia del cursor solo cuando apunte a una entrada válida.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52452)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige los accesos a las ranuras de la pila uninit. Se supone que los programas privilegiados pueden leer la memoria de la pila no inicializada (desde 6715df8d5) pero, antes de este parche, estos accesos se permitían de forma inconsistente. En particular, se permitían accesos por encima de state->allocated_stack, pero no por debajo de él. En otras palabras, si la pila ya era "lo suficientemente grande", se permitía el acceso, pero en caso contrario se rechazaba el acceso en lugar de permitir "hacer crecer la pila". Este rechazo no deseado ocurría en dos lugares: - en check_stack_slot_within_bounds() - en check_stack_range_initialized() Este parche dispone que estos accesos sean permitidos. Un montón de pruebas que dependían del antiguo rechazo tuvieron que cambiar; todos ellos se cambiaron para agregar que también se ejecutan sin privilegios, en cuyo caso el comportamiento anterior persiste. Una prueba no se pudo actualizar (global_func16) porque no se puede ejecutar sin privilegios por otros motivos. Este parche también corrige el seguimiento del tamaño de la pila para lecturas con desplazamiento variable. Esta segunda solución se incluye en la misma confirmación que la primera porque están interrelacionadas. Antes de este parche, las escrituras en la pila usando registros que contenían un desplazamiento variable (a diferencia de registros con valores fijos y conocidos) no contribuían adecuadamente al tamaño de pila necesario de la función. Como resultado, era posible que un programa verificara, pero luego intentara leer datos fuera de límites en tiempo de ejecución porque se le había asignado una pila demasiado pequeña. Cada función rastrea el tamaño de la pila que necesita en bpf_subprog_info.stack_ Depth, que es mantenido por update_stack_ Depth(). Para accesos regulares a la memoria, check_mem_access() estaba llamando a update_state_ Depth() pero pasaba solo la parte fija del registro de compensación, ignorando la variable compensación. Esto era incorrecto; en su lugar se debe utilizar el valor mínimo posible de ese registro. Este seguimiento ahora se soluciona centralizando el seguimiento del tamaño de la pila en grow_stack_state() y elevando las llamadas a grow_stack_state() a check_stack_access_within_bounds() como lo sugiere Andrii. El código ahora es más simple y rastrea de manera más convincente el tamaño máximo de pila correcto. check_stack_range_initialized() ahora puede confiar en que se haya asignado suficiente pila para el acceso; esto ayuda con la solución del primer problema. Se cambiaron algunas pruebas para verificar también el cálculo de la profundidad de la pila. El que falla sin este parche es verifier_var_off:stack_write_priv_vs_unpriv.
  • Vulnerabilidad en kernel de Linux (CVE-2024-26586)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige la corrupción de la pila Cuando los filtros tc se agregan por primera vez a un dispositivo de red, el puerto local correspondiente se vincula a un grupo ACL en el dispositivo. El grupo contiene una lista de ACL. A su vez, cada ACL apunta a una región TCAM diferente donde se almacenan los filtros. Durante el reenvío, las ACL se evalúan secuencialmente hasta que se encuentra una coincidencia. Una razón para colocar filtros en diferentes regiones es cuando se agregan con prioridades decrecientes y en orden alterno, de modo que dos filtros consecutivos nunca puedan caber en la misma región debido a su uso clave. En Spectrum-2 y ASIC más nuevos, el firmware comenzó a informar que la cantidad máxima de ACL en un grupo es superior a 16, pero el diseño del registro que configura los grupos de ACL (PAGT) no se actualizó para tener en cuenta eso. Por lo tanto, es posible sufrir daños en la pila [1] en el raro caso de que se requieran más de 16 ACL en un grupo. Se soluciona limitando el tamaño máximo del grupo de ACL al mínimo entre lo que informa el firmware y las ACL máximas que caben en el registro PAGT. Agregue un caso de prueba para asegurarse de que la máquina no falle cuando se cumpla esta condición. [1] Pánico del kernel - no se sincroniza: stack-protector: La pila del kernel está dañada en: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 pánico+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+ 0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach +0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb _add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb +0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x 40/0xe0 entrada_SYSCALL_64_after_hwframe+0x63/0x6b
  • Vulnerabilidad en kernel de Linux (CVE-2024-26587)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netdevsim: no intente destruir PHC en VF PHC se inicializa en nsim_init_netdevsim(), que sólo se llama si (nsim_dev_port_is_pf()). Cree una contraparte de nsim_init_netdevsim() y mueva el mock_phc_destroy() allí. Esto soluciona un fallo al intentar destruir netdevsim con VF instanciados, detectado al ejecutar la prueba devlink.sh: ERROR: desreferencia del puntero NULL del núcleo, dirección: 00000000000000b8 RIP: 0010:mock_phc_destroy+0xd/0x30 Seguimiento de llamadas: nsim_destroy+0x4a /0x70 [netdevsim] __nsim_dev_port_del+0x47/0x70 [netdevsim] nsim_dev_reload_destroy+0x105/0x120 [netdevsim] nsim_drv_remove+0x2f/0xb0 [netdevsim] dispositivo_release_driver_internal+0x1a1/0x210 bus_remove_device+0xd5/0x120 dispositivo_del+0x159/0x490 dispositivo_unregister+0x12/0x30 del_device_store +0x11a/0x1a0 [netdevsim] kernfs_fop_write_iter+0x130/0x1d0 vfs_write+0x30b/0x4b0 ksys_write+0x69/0xf0 do_syscall_64+0xcc/0x1e0 Entry_SYSCALL_64_after_hwframe+0x6f/0x77
  • Vulnerabilidad en kernel de Linux (CVE-2024-26588)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LoongArch: BPF: evita el acceso a la memoria fuera de los límites La prueba test_tag desencadena un error de página no controlada: # ./test_tag [130.640218] CPU 0 No se puede manejar la solicitud de paginación del kernel en virtual dirección ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Ups[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Contaminado: GDO 6.7.0-rc4 -loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [130.640764] Nombre de hardware: QEMU QEMU Máquina virtual, BIOS desconocido 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 13 0.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000 f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 00000000000000000 t1 00000000000007f6 t2 00000000000000000 t3 9000000004091b70 [ 130.641387] t4 00 0000006ba210be t5 0000000000000004 t6 ffffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 00000000000000005 u0 0000000000000dc0 s9 000000000 0000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 00000000000000095 s4 0000000000000000 [ 130.6 41771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9 000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE ) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EssubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 1 30.642815] Módulos vinculados en: [última descarga : bpf_testmod(O)] [130.642924] Procesar test_tag (pid: 1326, threadinfo=00000000f7f4015f, tarea=000000006499f9fd) [130.643062] Pila: 0000000000000000 900000000338072 4 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0 000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 00000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 00000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 00000000000000 000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 0 00007ffffb917790 90000000032acfb0 [ 130.644572] . .. [ 130.644629] Seguimiento de llamadas: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 1 30.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b838 8>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [ 130.645507] [ 130.645539] Código: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014 cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ final de seguimiento 0000000000000000 ]--- En mi máquina, que tiene CONFIG_PAGE_SIZE_16KB=y, la prueba falló al cargar un programa BPF con 2039 instrucciones: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncado---
  • Vulnerabilidad en kernel de Linux (CVE-2024-26589)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Rechazar variable offset alu en PTR_TO_FLOW_KEYS Para PTR_TO_FLOW_KEYS, check_flow_keys_access() solo usa fijo para la validación. Sin embargo, el desplazamiento variable ptr alu no está prohibido para este tipo de ptr. Por lo tanto, el desplazamiento variable no se verifica. Se acepta el siguiente programa: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flujo_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=escalar() 4: (57) r8 &= 1024 ; R8_w=escalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 pila= antes de 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 pila= antes de 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 pila= antes de 2: (b7 ) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=escalar(smin=smin32=0,smax=umax=smax32= umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) salida Este programa carga flow_keys en r7, agrega la variable offset r8 a r7 y finalmente causa acceso fuera de límites: ERROR: no se puede manejar el error de página para la dirección: ffffc90014c80038 [. ..] Seguimiento de llamadas: bpf_dispatcher_nop_func include/linux/bpf.h:1231 [en línea] __bpf_prog_run include/linux/filter.h:651 [en línea] bpf_prog_run include/linux/filter.h:658 [en línea] bpf_prog_run_pin_on_cpu include /linux/filter.h:675 [Inline] BPF_FLOW_DISSECT+0x15f/0x350 net/Core/Flow_Dissector.C: 991 BPF_Prog_Test_Run_Flow_Dissector+0x39D/0x620 NET/BPF/Test_Run.C: 1359 BPF_PRF_TISM 4107 [ en línea] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5559 [en línea] __x64_sys_bpf+0x73 /0xb0 kernel/bpf /syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Solucionar esto rechazando ptr alu con variable compensación en flow_keys. La aplicación del parche rechaza el programa con "La aritmética de puntero R7 en flow_keys está prohibida".
  • Vulnerabilidad en kernel de Linux (CVE-2024-26590)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige el formato de compresión por archivo inconsistente EROFS puede seleccionar algoritmos de compresión por archivo, y cada algoritmo de compresión por archivo debe marcarse en el superbloque del disco para la inicialización. Sin embargo, syzkaller puede generar imágenes manipuladas inconsistentes que usan un tipo de algoritmo no compatible para inodos específicos, por ejemplo, usa el tipo de algoritmo MicroLZMA incluso si no está configurado en `sbi->available_compr_algs`. Esto puede provocar un "ERROR: desreferencia del puntero NULL del kernel" inesperado si el descompresor correspondiente no está integrado. Solucione este problema comprobando con `sbi->available_compr_algs` para cada solicitud de m_algorithmformat. El mapa de bits preestablecido !erofs_sb_has_compr_cfgs incorrecto ahora se corrige porque antes era inofensivo.
  • Vulnerabilidad en kernel de Linux (CVE-2024-26591)
    Severidad: Pendiente de análisis
    Fecha de publicación: 22/02/2024
    Fecha de última actualización: 18/03/2024
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: Se corrigió la rama de re-adjunción en bpf_tracing_prog_attach El siguiente caso puede causar un bloqueo debido a la falta de adjunto_btf: 1) cargar el programa rawtp 2) cargar el programa fentry con rawtp como target_fd 3) crear enlace de seguimiento para el programa fentry con target_fd = 0 4) repetir 3 Al final tenemos: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (porque no proporcionamos target_fd para link_create) - prog->aux ->attach_btf == NULL (el programa se cargó con adjunto_prog_fd=X) - el programa se cargó para tgt_prog pero no tenemos forma de averiguar cuál ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000058 Seguimiento de llamadas: ? __morir+0x20/0x70 ? page_fault_oops+0x15b/0x430? fixup_exception+0x22/0x330? exc_page_fault+0x6f/0x170? asm_exc_page_fault+0x22/0x30? bpf_tracing_prog_attach+0x279/0x560? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/ 0x76 Devuelve -EINVAL en esta situación.