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 Mblog Blog system v.3.5.0 (CVE-2024-28713)
Severidad: CRÍTICA
Fecha de publicación: 28/03/2024
Fecha de última actualización: 23/09/2025
Un problema en Mblog Blog system v.3.5.0 permite a un atacante ejecutar código arbitrario a través de un archivo manipulado en la función de administración de temas.
-
Vulnerabilidad en Sane 1.2.1 (CVE-2023-46047)
Severidad: ALTA
Fecha de publicación: 27/03/2024
Fecha de última actualización: 23/09/2025
Un problema en Sane 1.2.1 permite a un atacante local ejecutar código arbitrario a través de un archivo manipulado en la función sanei_configure_attach(). NOTA: esto está en disputa porque no se espera que el producto comience con un archivo de configuración controlado por el atacante.
-
Vulnerabilidad en Sane 1.2.1 (CVE-2023-46052)
Severidad: ALTA
Fecha de publicación: 27/03/2024
Fecha de última actualización: 23/09/2025
Vulnerabilidad en la sobrescritura de los límites de almacenamiento dinámico Sane 1.2.1 en init_options() desde backend/test.c a través de una cadena larga init_mode en un archivo de configuración. NOTA: esto está en disputa porque no se espera que el código test.c se ejecute con un archivo de configuración controlado por el atacante.
-
Vulnerabilidad en Collabora Online (CVE-2024-29182)
Severidad: MEDIA
Fecha de publicación: 04/04/2024
Fecha de última actualización: 23/09/2025
Collabora Online es una suite ofimática colaborativa en línea basada en LibreOffice. Se encontró una vulnerabilidad de Cross-Site Scripting almacenada en Collabora Online. Un atacante podría crear un documento con un payload XSS en el texto del documento al que se hace referencia por campo que, si se pasa por encima para generar información sobre herramientas, podría ser ejecutado por el navegador del usuario. Los usuarios deben actualizar a Collabora Online 23.05.10.1 o superior. Las series anteriores de Collabora Online, 22.04, 21.11, etc. no se ven afectadas.
-
Vulnerabilidad en TensorFlow (CVE-2024-3660)
Severidad: CRÍTICA
Fecha de publicación: 16/04/2024
Fecha de última actualización: 23/09/2025
Una vulnerabilidad de inyección de código arbitrario en el framework Keras de TensorFlow (<2.13) permite a los atacantes ejecutar código arbitrario con los mismos permisos que la aplicación utilizando un modelo que permite código arbitrario independientemente de la aplicación.
-
Vulnerabilidad en autoexpress v.1.3.0 (CVE-2024-30974)
Severidad: ALTA
Fecha de publicación: 19/04/2024
Fecha de última actualización: 23/09/2025
La vulnerabilidad de inyección SQL en autoexpress v.1.3.0 permite a los atacantes ejecutar comandos SQL arbitrarios a través del parámetro carId.
-
Vulnerabilidad en Ecommerce-CodeIgniter-Bootstrap (CVE-2024-31820)
Severidad: CRÍTICA
Fecha de publicación: 29/04/2024
Fecha de última actualización: 23/09/2025
Un problema en el commit Ecommerce-CodeIgniter-Bootstrap v. d22b54e8915f167a135046ceb857caaf8479c4da permite a un atacante remoto ejecutar código arbitrario a través del método getLangFolderForEdit del componente Languages.php.
-
Vulnerabilidad en Ecommerce-CodeIgniter-Bootstrap (CVE-2024-31821)
Severidad: ALTA
Fecha de publicación: 29/04/2024
Fecha de última actualización: 23/09/2025
Vulnerabilidad de inyección SQL en el commit Ecommerce-CodeIgniter-Bootstrap v. d22b54e8915f167a135046ceb857caaf8479c4da permite a un atacante remoto ejecutar código de su elección a través del método ManageQuantitiesAndProcurement del componente Orders_model.php.
-
Vulnerabilidad en Ecommerce-CodeIgniter-Bootstrap (CVE-2024-31822)
Severidad: CRÍTICA
Fecha de publicación: 29/04/2024
Fecha de última actualización: 23/09/2025
Un problema en el commit Ecommerce-CodeIgniter-Bootstrap v. d22b54e8915f167a135046ceb857caaf8479c4da permite a un atacante remoto ejecutar código arbitrario a través del método saveLanguageFiles del componente Languages.php.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47447)
Severidad: MEDIA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm/a3xx: corrige el manejo de errores en a3xx_gpu_init() Estas rutas de error devolvieron 1 en caso de falla, en lugar de un código de error negativo. Esto provocaría un Ups en la persona que llama. Un segundo problema es que la verificación de "if (ret! = -ENODATA)" no funcionó porque "ret" estaba establecido en 1.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47448)
Severidad: MEDIA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige posible bloqueo en recvmsg() recvmsg() puede entrar en un bucle infinito si la persona que llama proporciona MSG_WAITALL, los datos presentes en la cola de recepción no son suficientes para cumplir con la solicitud y el par no recibe más datos. Cuando sucede lo anterior, mptcp_wait_data() siempre regresará sin espera, ya que el indicador MPTCP_DATA_READY verificado por dicha función se establece y nunca se borra en dicha ruta de código. Aprovechar el syzbot anterior fue capaz de desencadenar una parada de RCU: rcu: INFO: rcu_preempt parada autodetectada en la CPU rcu: 0-...!: (10499 marca este GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1 (t=10500 jiffies g=13089 q=109) rcu: rcu_preempt ¡kthread se quedó sin 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1 rcu: A menos que rcu_preempt kthread obtenga suficiente tiempo de CPU, ahora se espera que OOM sea el comportamiento. rcu: Volcado de pila de kthread del período de gracia de RCU: tarea: rcu_preempt estado: R pila de tareas en ejecución: 28696 pid: 14 ppid: 2 banderas: 0x00004000 Seguimiento de llamadas: context_switch kernel/sched/core.c:4955 [en línea] __schedule+0x940/ 0x26f0 kernel/sched/core.c:6236 Schedule+0xd3/0x270 kernel/sched/core.c:6315 Schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881 rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c :1955 rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 rcu: Volcado de pila donde RCU Última ejecución de GP kthread: Envío de NMI desde la CPU 0 a las CPU 1: seguimiento de NMI para la CPU 1 CPU: 1 PID: 8510 Comm: syz-executor827 No contaminado 5.15.0-rc2-next-20210920-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [en línea] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [en línea] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [en línea] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [en línea] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [en línea] RIP : 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189 Código: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 <48> 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00 RSP: 0018:ffffc9000cd676c8 EFLAGS: 000283 RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX : ffffffff88ea062a RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870 RBP: ffffed100e9a110e R08: 0000000000000001 R09: d08877 R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000 R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000 0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 S: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0 0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: instrument_atomic_ lectura_escritura incluye/linux/ instrumented.h:101 [en línea] test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [en línea] mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016 release_sock+0xb4/0x1b0 net/core/ sock.c:3204 mptcp_wait_data net/mptcp/protocol.c:1770 [en línea] mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080 inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659 vmsg_nosec red/socket .c:944 [en línea] ____sys_recvmsg+0x527/0x600 net/socket.c:2626 ___sys_recvmsg+0x127/0x200 net/socket.c:2670 do_recvmmsg+0x24d/0x6d0 net/socket.c:2764 net/socket.c: 2843 [en línea] __do_sys_recvmmsg net/socket.c:2866 [en línea] __se_sys_recvmmsg net/socket.c:2859 [en línea] ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49202)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_uart: falta de comprobación NULL en h5_enqueue Syzbot encontró un fallo de protección general en __pm_runtime_resume(). El problema estaba en la falta de comprobación NULL. hu->serdev puede ser NULL y no deberíamos pasar ciegamente &serdev->dev en algún lugar, ya que provocará GPF.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49205)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige la doble descarga de la memoria de sk_msg. Si tcp_bpf_sendmsg se está ejecutando durante una operación de desmantelamiento, psock puede liberarse. tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() Unlikely(!psock)) sk_msg_free() La memoria de msg ha sido descargada en tcp_bpf_send_verdict() por sk_msg_return(), y sería descargada nuevamente por sk_msg_free(). Cuando psock es nulo, podemos simplemente devolver un código de error, esto activaría sk_msg_free_nocharge en la ruta de error de __SK_REDIRECT y tendría el efecto secundario de arrojar un error al espacio del usuario. Esto sería un ligero cambio en el comportamiento del lado del usuario, pero se vería igual que un error si la redirección en el socket arrojara un error. Este problema puede causar la siguiente información: ADVERTENCIA: CPU: 0 PID: 2136 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Seguimiento de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
-
CVE-2022-49214
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64s: No usar DSISR para fallas SLB Desde el commit 46ddcb3950a2 ("powerpc/mm: Mostrar si un fallo de página incorrecta en los datos es de lectura o escritura") usamos page_fault_is_write(regs->dsisr) en __bad_page_fault() para determinar si el fallo es de lectura o escritura y cambiar el mensaje impreso en consecuencia. Pero las fallas SLB, también conocidas como interrupciones de segmento de datos, no establecen DSISR (registro de estado de interrupción de almacenamiento de datos) en un valor útil. Todas las versiones de ISA desde la v2.03 hasta la v3.1 especifican que la interrupción de segmento de datos establece DSISR "en un valor indefinido". Hasta donde puedo ver, tampoco se menciona que los fallos SLB establezcan DSISR en ningún contenido de BookIV. Esto se manifiesta como accesos que deberían ser de lectura que se informan incorrectamente como escrituras, por ejemplo, al usar el comando "dump" de xmon: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en escritura en 0x5deadbeef0000000 [359526.415611][ C6] Dirección de instrucción con fallas: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) en [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 Si desmontamos la PC, vemos una instrucción de carga: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) También podemos ver en exceptions-64s.S que el bloque data_access_slb no establece IDSISR=1, lo que significa que no carga DSISR en pt_regs. Por lo tanto, el valor que estamos usando para determinar si el error es de lectura/escritura es algún valor obsoleto en pt_regs de un error de página anterior. Reelabore la lógica de impresión para separar el caso de error de SLB y solo imprima lectura/escritura en los casos en los que podamos determinarlo. El resultado se parece a, por ejemplo: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en 0x5deadbeef0000000 [ 721.779697][ C6] Dirección de instrucción con error: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 [ 742.793316][ C6] Instrucción con error dirección: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390]
-
Vulnerabilidad en kernel de Linux (CVE-2022-49222)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/bridge: anx7625: Se soluciona el problema de desbordamiento al leer EDID La longitud del bloque EDID puede ser mayor a 256 bytes, por lo que deberíamos usar `int` en lugar de `u8` para la variable `edid_pos`.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49228)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige un error de btf decl_tag al etiquetar una función syzbot informó un error de btf decl_tag con el siguiente seguimiento de pila: error de protección general, probablemente para una dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000000-0x0000000000000007] CPU: 0 PID: 3592 Comm: syz-executor914 No contaminado 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:btf_type_vlen include/linux/btf.h:231 [en línea] RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910 ... Seguimiento de llamadas: btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198 btf_check_all_types kernel/bpf/btf.c:4239 [en línea] btf_parse_type_sec kernel/bpf/btf.c:4280 [en línea] btf_parse kernel/bpf/btf.c:4513 [en línea] btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047 bpf_btf_load kernel/bpf/syscall.c:4039 [en línea] __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679 __do_sys_bpf kernel/bpf/syscall.c:4738 [en línea] __se_sys_bpf kernel/bpf/syscall.c:4736 [en línea] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736 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 El error kasan se activa con un BTF ilegal como el siguiente: tipo 0: void tipo 1: int tipo 2: decl_tag a func tipo 3 tipo 3: func a func_proto tipo 8 El número total de tipos es 4 y el tipo 3 es ilegal ya que su tipo func_proto está fuera de rango. Actualmente, el tipo de destino de decl_tag puede ser struct/union, var o func. Tanto struct/union como var implementaron sus propias funciones de devolución de llamada 'resolve' y, por lo tanto, se manejan correctamente en el kernel. Pero el tipo func no tiene la función de devolución de llamada 'resolve'. Cuando btf_decl_tag_resolve() intenta verificar el tipo func, intenta obtener vlen de su tipo func_proto, lo que activó el error kasan anterior. Para solucionar el problema, btf_decl_tag_resolve() debe ejecutar btf_func_check() antes de intentar acceder al tipo func_proto. En la implementación actual, el tipo func se verifica con btf_func_check() en la función de verificación principal btf_check_all_types(). Para solucionar el problema de kasan anterior, implementemos la devolución de llamada 'resolve' para el tipo func de manera adecuada. La devolución de llamada 'resolve' también se llamará en btf_check_all_types() para los tipos func.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49234)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: Evitar la sincronización entre chips del filtrado de VLAN Los cambios en el filtrado de VLAN no son aplicables a las notificaciones entre chips. En un sistema como este: .-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-' Antes de este cambio, al salir sw1p1 de un puente, también se realizaba una llamada a dsa_port_vlan_filtering a sw2p1 y sw3p1. En este escenario: .---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-' Cuando sw1p4 abandonara un puente, se llamaría a dsa_port_vlan_filtering para sw2 y sw3 con un puerto inexistente, lo que provocaría accesos fuera de los límites de la matriz y fallos en mv88e6xxx.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49244)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: mt8192-mt6359: Se corrige la gestión de errores en mt8192_mt6359_dev_probe El puntero device_node es devuelto por of_parse_phandle() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esta función solo llama a of_node_put() en la ruta regular. Y provocará una fuga de refcount en las rutas de error. Corrija esto llamando también a of_node_put() en la gestión de errores.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49245)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: rockchip: Se corrige la referencia de uso de PM de rockchip_i2s_tdm_resume pm_runtime_get_sync, que incrementará el contador de uso de PM incluso si falla. Olvidar la operación de colocación provocará una fuga de referencia aquí. Lo solucionamos reemplazándolo con pm_runtime_resume_and_get para mantener equilibrado el contador de uso.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49246)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: atmel: Se corrige la gestión de errores en snd_proto_probe El puntero device_node es devuelto por of_parse_phandle() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esta función solo llama a of_node_put() en la ruta regular. Y provocará una fuga de refcount en las rutas de error. Corrija esto llamando también a of_node_put() en la gestión de errores.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49248)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: firewire-lib: corrige el indicador no inicializado para las transacciones diferidas de AV/C. Las transacciones diferidas de AV/C tenían soporte en una confirmación 00a7bb81c20f ("ALSA: firewire-lib: agregar soporte para transacciones diferidas"), mientras que el indicador 'diferible' se puede desinicializar para transacciones AV/C que no sean de control/notificación. UBSAN lo informa: kernel: == ... 5/AX370-Gaming 5, BIOS F42b 01/08/2019 núcleo: Seguimiento de llamadas: núcleo: kernel: show_stack+0x52/0x58 kernel: dump_stack_lvl+0x4a/0x5f kernel: dump_stack+0x10/0x12 kernel: ubsan_epilogue+0x9/0x45 kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49 kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib] kernel: fcp_response+0x28/0x30 [snd_firewire_lib] kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core] kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core] kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci] kernel: tasklet_action_common.constprop.0+0xea/0xf0 kernel: tasklet_action+0x22/0x30 kernel: __do_softirq+0xd9/0x2e3 kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0 kernel: do_softirq+0x75/0xa0 kernel: kernel: kernel: __local_bh_enable_ip+0x50/0x60 kernel: irq_forced_thread_fn+0x7e/0x90 kernel: irq_thread+0xba/0x190 kernel: ? irq_thread_fn+0x60/0x60 kernel: kthread+0x11e/0x140 kernel: ? irq_thread_check_affinity+0xf0/0xf0 kernel: ? set_kthread_struct+0x50/0x50 kernel: ret_from_fork+0x22/0x30 kernel: kernel: ================================================================================ Esta confirmación corrige el error. El error no tiene ninguna desventaja para las transacciones AV/C que no son de control/notificación, ya que el indicador tiene un efecto para la respuesta AV/C con estado INTERIM (0x0f), que no se utiliza para las transacciones en la especificación general AV/C.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49249)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: wc938x: se corrige el acceso a una matriz fuera de los límites para el tipo de enumeración. El acceso a enumeraciones mediante números enteros daría como resultado un acceso a una matriz fuera de los límites en plataformas como aarch64 donde sizeof(long) es 8 en comparación con el tamaño de la enumeración, que es de 4 bytes. Corrija esto utilizando elementos enumerados en lugar de números enteros.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49250)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: rx-macro: fix accessing compander for aux AUX interpolator does not have compander, so check before accessing compander data for this. Without this check, an array of out bounds access will be made in comp_enabled[] array. El interpolador AUX no tiene compander, por lo que se debe verificar esto antes de acceder a los datos del compander. Sin esta verificación, se realizará un acceso a la matriz de los límites de salida en la matriz comp_enabled[].
-
Vulnerabilidad en kernel de Linux (CVE-2022-49251)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: va-macro: se corrige el acceso a una matriz fuera de los límites para el tipo de enumeración. Acceder a enumeraciones usando números enteros daría como resultado un acceso a una matriz fuera de los límites en plataformas como aarch64, donde sizeof(long) es 8 en comparación con el tamaño de la enumeración, que es de 4 bytes.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49252)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: rx-macro: se corrige el acceso a una matriz fuera de los límites para el tipo de enumeración. Acceder a enumeraciones usando números enteros daría como resultado un acceso a una matriz fuera de los límites en plataformas como aarch64, donde sizeof(long) es 8 en comparación con el tamaño de la enumeración, que es de 4 bytes.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49253)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: usb: go7007: s2250-board: corrección de fuga en probe() Llamada a i2c_unregister_device(audio) en esta ruta de error.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49254)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ti-vpe: cal: Se corrige una desreferencia de puntero NULL en cal_ctx_v4l2_init_formats() En cal_ctx_v4l2_init_formats(), devm_kzalloc() se asigna a ctx->active_fmt y hay una desreferencia de este después de eso, lo que podría provocar una desreferencia de puntero NULL en caso de fallo de devm_kzalloc(). Corrija este error agregando una comprobación NULL de ctx->active_fmt. Este error fue encontrado por un analizador estático. Las compilaciones con 'make allyesconfig' no muestran nuevas advertencias y nuestro analizador estático ya no advierte sobre este código.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49256)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watch_queue: En realidad, libera el reloj. free_watch() hace todo lo posible, excepto liberar realmente el objeto de vigilancia. Solucione esto agregando el kfree faltante. kmemleak produce un informe similar al siguiente. Tenga en cuenta que, como se puede ver una dirección en la primera palabra, el reloj parecería haber pasado por call_rcu(). ERROR: pérdida de memoria objeto no referenciado 0xffff88810ce4a200 (tamaño 96): comm "syz-executor352", pid 3605, jiffies 4294947473 (edad 13.720s) volcado hexadecimal (primeros 32 bytes): e0 82 48 0d 81 88 ff ff 00 00 00 00 00 00 00 00 ..H............. 80 a2 e4 0c 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc include/linux/slab.h:581 [inline] [] kzalloc include/linux/slab.h:714 [inline] [] keyctl_watch_key+0xec/0x2e0 security/keys/keyctl.c:1800 [] __do_sys_keyctl+0x3c4/0x490 security/keys/keyctl.c:2016 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x44/0xae
-
Vulnerabilidad en kernel de Linux (CVE-2022-49257)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watch_queue: Se corrige la desreferencia NULL en la limpieza de errores En watch_queue_set_size(), el código de limpieza de errores no tiene en cuenta el hecho de que __free_page() no puede manejar un puntero NULL al intentar liberar páginas de búfer que sí se asignaron. Solucione esto llamando a __free_page() solo en las páginas realmente asignadas. Sin la corrección, esto puede llevar a algo como lo siguiente: ERROR: KASAN: null-ptr-deref en __free_pages+0x1f/0x1b0 mm/page_alloc.c:5473 Lectura de tamaño 4 en la dirección 0000000000000034 por la tarea syz-executor168/3599 ... Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 __kasan_report mm/kasan/report.c:446 [en línea] kasan_report.cold+0x66/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:71 [en línea] atomic_read include/linux/atomic/atomic-instrumented.h:27 [en línea] page_ref_count include/linux/page_ref.h:67 [en línea] put_page_testzero include/linux/mm.h:717 [en línea] __free_pages+0x1f/0x1b0 mm/page_alloc.c:5473 watch_queue_set_size+0x499/0x630 kernel/watch_queue.c:275 pipe_ioctl+0xac/0x2b0 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+0x193/0x200 fs/ioctl.c:860 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
-
Vulnerabilidad en kernel de Linux (CVE-2022-49261)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gem: agregar comprobación de los límites faltante en vm_access Una comprobación de los límites faltante en vm_access() puede provocar una lectura o escritura fuera de los límites en el área de memoria adyacente, ya que el atributo len no se valida antes de memcpy más adelante en la función, lo que potencialmente afecta a: [ 183.637831] ERROR: no se puede manejar la falla de página para la dirección: ffffc90000c86000 [ 183.637934] #PF: acceso de lectura de supervisor en modo kernel [ 183.637997] #PF: error_code(0x0000) - página no presente [ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0 [ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI [ 183.638201] CPU: 3 PID: 1790 Comm: poc Contaminado: GD 5.17.0-rc6-ci-drm-11296+ #1 [ 183.638298] Nombre del hardware: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 30/05/2019 [ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10 [ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246 [ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc [ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004 [ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000 [ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 00000000000001000 [ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000 [ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000 [ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0 [ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000000000 [ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 183.650142] Seguimiento de llamadas: [ 183.650988] [ 183.651793] vm_access+0x1f0/0x2a0 [i915] [ 183.652726] __access_remote_vm+0x224/0x380 [ 183.653561] mem_rw.isra.0+0xf9/0x190 [ 183.654402] vfs_read+0x9d/0x1b0 [ 183.655238] ksys_read+0x63/0xe0 [ 183.656065] do_syscall_64+0x38/0xc0 [ 183.656882] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 183.657663] RIP: 0033:0x7fe5ef725142 [ 183.659351] RSP: 002b:00007ffe1e81c7e8 EFLAGS: 00000246 ORIG_RAX: 000000000000000 [ 183.660227] RAX: ffffffffffffffda RBX: 0000557055dfb780 RCX: 00007fe5ef725142 [ 183.661104] RDX: 0000000000001000 RSI: 00007ffe1e81d880 RDI: 000000000000005 [ 183.661972] RBP: 00007ffe1e81e890 R08: 0000000000000030 R09: 0000000000000046 [ 183.662832] R10: 0000557055dfc2e0 R11: 0000000000000246 R12: 0000557055dfb1c0 [ 183.663691] R13: 00007ffe1e81e980 R14: 000000000000000 R15: 000000000000000 Cambios desde v1: - Condición if actualizada con range_overflows_t [Chris Wilson] [mauld: ordena el mensaje de confirmación y agrega Cc: estable] (seleccionado de el commit 661412e301e2ca86799aa4f400d1cf0bd38c57c6)
-
Vulnerabilidad en kernel de Linux (CVE-2022-49262)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: octeontx2 - eliminar la comprobación CONFIG_DM_CRYPT No se encontraron problemas al usar el controlador con dm-crypt habilitado. Por lo tanto, se puede eliminar la comprobación CONFIG_DM_CRYPT en el controlador. Esto también corrige la desreferencia del puntero NULL en la versión del controlador si CONFIG_DM_CRYPT está habilitado. ... No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000008 ... Rastreo de llamadas: crypto_unregister_alg+0x68/0xfc crypto_unregister_skciphers+0x44/0x60 otx2_cpt_crypto_exit+0x100/0x1a0 otx2_cptvf_remove+0xf8/0x200 pci_device_remove+0x3c/0xd4 __device_release_driver+0x188/0x234 device_release_driver+0x2c/0x4c ...
-
Vulnerabilidad en kernel de Linux (CVE-2022-49263)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: brcmfmac: pcie: Liberar firmwares en la ruta de error brcmf_pcie_setup Esto evita la pérdida de memoria si falla brcmf_chip_get_raminfo. Tenga en cuenta que el blob CLM se libera en la ruta de eliminación del dispositivo.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49268)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: Se corrige la desreferencia de puntero NULL cuando ENOMEM No llame a snd_dma_free_pages() cuando snd_dma_alloc_pages() devuelve -ENOMEM porque conduce a un error de desreferencia de puntero NULL. El dmesg dice: [ T1387] sof-audio-pci-intel-tgl 0000:00:1f.3: error: falla de asignación de memoria: -12 [ T1387] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 [ T1387] #PF: acceso de lectura del supervisor en modo kernel [ T1387] #PF: error_code(0x0000) - página no presente [ T1387] PGD 0 P4D 0 [ T1387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ T1387] CPU: 6 PID: 1387 Comm: alsa-sink-HDA A Tainted: GW 5.17.0-rc4-superb-owl-00055-g80d47f5de5e3 [ T1387] Nombre del hardware: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 15/09/2021 [ T1387] RIP: 0010:dma_free_noncontiguous+0x37/0x80 [ T1387] Código: [... fragmento ...] [ T1387] RSP: 0000:ffffc90002b87770 EFLAGS: 00010246 [ T1387] RAX: 000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ T1387] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888101db30d0 [ T1387] RBP: 00000000ffffff4 R08: 000000000000000 R09: 000000000000000 [ T1387] R10: 000000000000000 R11: ffffc90002b874d0 R12: 000000000000001 [ T1387] R13: 0000000000058000 R14: ffff888105260c68 R15: ffff888105260828 [ T1387] FS: 00007f42e2ffd640(0000) GS:ffff888466b80000(0000) knlGS:0000000000000000 [ T1387] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ T1387] CR2: 0000000000000000 CR3: 000000014acf0003 CR4: 0000000000770ee0 [ T1387] PKRU: 55555554 [ T1387] Rastreo de llamadas: [ T1387] [ T1387] cl_stream_prepare+0x10a/0x120 [snd_sof_intel_hda_common 146addf995b9279ae7f509621078cccbe4f875e1] [... recorte ...] [ T1387]
-
Vulnerabilidad en kernel de Linux (CVE-2022-49271)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: evitar longitudes de salida incorrectas en smb2_ioctl_query_info() Al llamar a smb2_ioctl_query_info() con smb_query_info::flags=PASSTHRU_FSCTL y smb_query_info::output_buffer_length=0, lo siguiente devolvería 0x10 buffer = memdup_user(arg + sizeof(struct smb_query_info), qi.output_buffer_length); if (IS_ERR(buffer)) { kfree(vars); return PTR_ERR(buffer); } en lugar de un puntero válido, lo que hace que la comprobación de IS_ERR() falle. Esto provocaría una deferencia ptr NULL en @buffer al acceder a él más tarde en smb2_ioctl_query_ioctl(). Mientras tanto, evite tener un @buffer más pequeño que 8 bytes para manejar correctamente las solicitudes SMB2_SET_INFO FileEndOfFileInformation cuando smb_query_info::flags=PASSTHRU_SET_INFO. Aquí hay un pequeño reproductor de C que activa un ptr NULL en @buffer cuando pasa un smb_query_info::flags no válido #include #include #include #include #include #include #define die(s) perror(s), exit(1) #define QUERY_INFO 0xc018cf07 int main(int argc, char *argv[]) { int fd; if (argc < 2) exit(1); fd = open(argv[1], O_RDONLY); si (fd == -1) morir("abrir"); si (ioctl(fd, QUERY_INFO, (uint32_t[]) { 0, 0, 0, 4, 0, 0}) == -1) morir("ioctl"); cerrar(fd); devolver 0; } mount.cifs //srv/share /mnt -o ... gcc repro.c && ./a.out /mnt/f0 [ 114.138620] fallo de protección general, probablemente para dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 114.139310] KASAN: null-ptr-deref en rango [0x000000000000000-0x0000000000000007] [ 114.139775] CPU: 2 PID: 995 Comm: a.out No contaminado 5.17.0-rc8 #1 [ 114.140148] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 01/04/2014 [ 114.140818] RIP: 0010:smb2_ioctl_query_info+0x206/0x410 [cifs] [ 114.141221] Código: 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 c8 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 7b 28 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9c 01 00 00 49 8b 3f e8 58 02 fb ff 48 8b 14 24 [ 114.142348] RSP: 0018:ffffc90000b47b00 EFLAGS: 00010256 [ 114.142692] RAX: dffffc0000000000 RBX: ffff888115503200 RCX: fffffffa020580d [ 114.143119] RDX: 00000000000000000 RSI: 000000000000000004 RDI: fffffffa043a380 [ 114.143544] PBR: ffff888115503278 R08: 0000000000000001 R09: 00000000000000003 [ 114.143983] R10: fffffbfff4087470 R11: 0000000000000001 R12: ffff888115503288 [ 114.144424] R13: 00000000ffffffea R14: ffff888115503228 R15: 0000000000000000 [ 114.144852] FS: 00007f7aeabdf740(0000) GS:ffff888151600000(0000) knlGS:00000000000000000 [ 114.145338] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 114.145692] CR2: 00007f7aeacfdf5e CR3: 000000012000e000 CR4: 0000000000350ee0 [ 114.146131] Seguimiento de llamadas: [ 114.146291] [ 114.146432] ? smb2_query_reparse_tag+0x890/0x890 [cifs] [ 114.146800] ? cifs_mapchar+0x460/0x460 [cifs] [ 114.147121] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.147412] ? cifs_strndup_to_utf16+0x15b/0x250 [cifs] [ 114.147775] ? dentry_path_raw+0xa6/0xf0 [ 114.148024] ? cifs_convert_path_to_utf16+0x198/0x220 [cifs] [ 114.148413] ? smb2_check_message+0x1080/0x1080 [cifs] [ 114.148766] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.149065] cifs_ioctl+0x1577/0x3320 [cifs] [ 114.149371] ? lock_downgrade+0x6f0/0x6f0 [ 114.149631] ? cifs_readdir+0x2e60/0x2e60 [cifs] [ 114.149956] ? rcu_read_lock_sched_held+0x3f/0x70 [ 114.150250] ? __rseq_handle_notify_resume+0x80b/0xbe0 [ 114.150562] ? __up_read+0x192/0x710 [ 114.150791] ? __ia32_sys_rseq+0xf0/0xf0 [ 114.151025] ? __x64_sys_openat+0x11f/0x1d0 [ 114.151296] __x64_sys_ioctl+0x127/0x190 [ 114.151549] do_syscall_64+0x3b/0x90 [ 114.151768] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 114.152079] RIP: 0033:0x7f7aead043df [ 114.152306] Código: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49272)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Arreglar un posible bloqueo AB/BA con buffer_mutex y mmap_lock syzbot capturó un posible punto muerto entre PCM runtime->buffer_mutex y mm->mmap_lock. Fue provocado por la corrección reciente para cubrir la lectura/escritura acelerada y otras ioctl, y en esa confirmación, pasé por alto un caso extremo (con suerte el único) que puede tomar el bloqueo de reversión, es decir, el mmap de OSS. La operación mmap de OSS permite excepcionalmente reconfigurar los parámetros dentro de la llamada al sistema mmap de OSS, donde ya se mantiene mm->mmap_mutex. Mientras tanto, las llamadas copy_from/to_user en operaciones de lectura/escritura también toman el mm->mmap_lock internamente, por lo tanto, puede llevar a un punto muerto AB/BA. Ya se vio un problema similar en el pasado y lo arreglamos con un refcount (en el commit b248371628aa). La corrección anterior solo cubría las rutas de llamadas con lectura/escritura de OSS y controles ioctl de OSS, mientras que ahora necesitamos cubrir el acceso concurrente a través de las API de ALSA y OSS. Este parche soluciona el problema anterior al reemplazar el bloqueo buffer_mutex en las operaciones de lectura/escritura con un refcount similar al que hemos usado para OSS. El nuevo campo, runtime->buffer_accessing, mantiene el número de operaciones de lectura/escritura concurrentes. A diferencia de la protección buffer_mutex anterior, esto protege solo alrededor de las llamadas copy_from/to_user(); los otros códigos están básicamente protegidos por el bloqueo de flujo PCM. El refcount puede ser negativo, lo que significa que está bloqueado por los controles ioctl. Si se ve un valor negativo, la lectura/escritura se cancela con -EBUSY. En el lado de los controles ioctl, por otro lado, también verifican este refcount y lo establecen en un valor negativo para bloquear a menos que ya se esté accediendo a él.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49274)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: se corrige un fallo al montar con la cuota habilitada Se ha informado de un fallo al montar ocfs2 con la cuota habilitada. RIP: 0010:ocfs2_qinfo_lock_res_init+0x44/0x50 [ocfs2] Seguimiento de llamadas: ocfs2_local_read_info+0xb9/0x6f0 [ocfs2] dquot_load_quota_sb+0x216/0x470 dquot_load_quota_inode+0x85/0x100 ocfs2_enable_quotas+0xa0/0x1c0 [ocfs2] ocfs2_fill_super.cold+0xc8/0x1bf [ocfs2] mount_bdev+0x185/0x1b0 legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 path_mount+0x465/0xac0 __x64_sys_mount+0x103/0x140 Esto se debe a que, al inicializar dqi_gqlock, los dqi_type y dqi_sb correspondientes no se inicializan correctamente. Este problema lo introduce el commit 6c85c2c72819, que quiere evitar el acceso a variables no inicializadas en casos de error. Por lo tanto, haga que la información de cuota global se inicialice correctamente.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49278)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: Se corrige la comprobación de recuento en rproc_coredump_write(). Se comprueba que el recuento sea 0 para evitar un posible desbordamiento. Se hace que la comprobación sea la misma que en rproc_recovery_write().
-
Vulnerabilidad en kernel de Linux (CVE-2022-49283)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: sysfb: se corrige la fuga del dispositivo de plataforma en la ruta de error. Asegúrese de liberar el dispositivo de plataforma también en el improbable caso de que falle el registro.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49285)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: accel: mma8452: usa la lógica correcta para obtener mma8452_data La lógica original para obtener mma8452_data es incorrecta, el punto *dev al dispositivo pertenece a iio_dev. No podemos usar este dev para encontrar el i2c_client correcto. La lógica original funcionó porque finalmente usó dev->driver_data para obtener iio_dev. Aquí, usar la API to_i2c_client() es incorrecto y confunde al lector. Para corregir la lógica, debería ser así struct mma8452_data *data = iio_priv(dev_get_drvdata(dev)); Pero después de el commit 8b7651f25962 ("iio: iio_device_alloc(): eliminar drvdata propios innecesarios"), la lógica superior tampoco puede funcionar. Cuando se intenta mostrar la escala disponible en el espacio de usuario, se produce un volcado del kernel y una desreferencia del puntero NULL del manejador del kernel. Por lo tanto, se utiliza dev_to_iio_dev() para corregir la lógica. Dual corrige las etiquetas, ya que la segunda refleja cuándo se expuso el error, mientras que la primera refleja cuándo se introdujo el error original.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49320)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: zynqmp_dma: En el tipo de datos fix desc_size de struct zynqmp_dma_chan En las funciones zynqmp_dma_alloc/free_chan_resources hay un desbordamiento potencial en las siguientes expresiones. dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL); dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p); Los argumentos desc_size y ZYNQMP_DMA_NUM_DESCS eran de 32 bits. Aunque esta condición de desbordamiento no se observa, es un problema potencial en el caso de la multiplicación de 32 bits. Por lo tanto, corríjala cambiando el tipo de datos desc_size a size_t. Además de corregir la cobertura, también reutilice la macro ZYNQMP_DMA_DESC_SIZE en el argumento de API dma_alloc_coherent. Direcciones: cobertura: evento overflow_before_widen.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49325)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: agregar descriptores de acceso para leer/establecer tp->snd_cwnd Tuvimos varios errores a lo largo de los años con código que rompía la suposición de que tp->snd_cwnd es mayor que cero. Últimamente, syzbot informó que se puede activar WARN_ON_ONCE(!tp->prior_cwnd) agregado en el commit 8b8a321ff72c ("tcp: corregir cwnd cero en tcp_cwnd_reduction"), y sin una reproducción tendríamos que dedicar un tiempo considerable a encontrar el error. En lugar de quejarnos demasiado tarde, queremos detectar dónde y cuándo tp->snd_cwnd se establece en un valor ilegal.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49330)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd syzbot recibió un nuevo informe [1] que finalmente apunta a un error muy antiguo, agregado en el soporte inicial para el sondeo de MTU. tcp_mtu_probe() tiene comprobaciones sobre el inicio de un sondeo de MTU si tcp_snd_cwnd(tp) >= 11. Pero nada impide que tcp_snd_cwnd(tp) se reduzca más tarde y antes de que el sondeo de MTU tenga éxito. Este error conduciría a posibles divisiones por cero. La depuración agregada en el commit 40570375356c ("tcp: add accessors to read/set tp->snd_cwnd") ha valido la pena :) Mientras estamos en ello, aborde los posibles desbordamientos en este código. [1] ADVERTENCIA: CPU: 1 PID: 14132 en include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Módulos vinculados en: CPU: 1 PID: 14132 Comm: syz-executor.2 No contaminado 5.18.0-syzkaller-07857-gbabf0bb978e3 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [en línea] RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Código: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287 RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000 RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520 R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50 R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000 FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [en línea] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [en línea] __se_sys_sendto net/socket.c:2127 [en línea] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entrada_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f6431289109 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109 RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 00000000000000246 R12: 0000000000000000 R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000
-
Vulnerabilidad en kernel de Linux (CVE-2022-49337)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: dlmfs: se corrige la gestión de errores de user_dlm_destroy_lock Cuando user_dlm_destroy_lock fallaba, no limpiaba las banderas que establecía antes de salir. Para USER_LOCK_IN_TEARDOWN, si esta función falla debido a que el bloqueo aún está en uso, la próxima vez que unlink invoque esta función, devolverá éxito y luego unlink eliminará el inodo y la dentry si el bloqueo no está en uso (archivo cerrado), pero el bloqueo dlm aún está vinculado en el recurso de bloqueo dlm, luego cuando bast ingrese, activará un pánico debido a use after free. Vea el siguiente seguimiento de llamada de pánico. Para solucionar esto, USER_LOCK_IN_TEARDOWN debe revertirse si falla. Y también debe devolverse un error si USER_LOCK_IN_TEARDOWN está configurado para informar al usuario que unlink falló. En el caso de que falle ocfs2_dlm_unlock, además de USER_LOCK_IN_TEARDOWN, también se requiere borrar USER_LOCK_BUSY. Aunque se libere el bloqueo de giro en el medio, pero USER_LOCK_IN_TEARDOWN aún esté configurado, para USER_LOCK_BUSY, si antes de cada lugar que espera en este indicador, se marca USER_LOCK_IN_TEARDOWN para que se libere, eso asegurará que ningún flujo espere en el indicador de ocupado establecido por user_dlm_destroy_lock(), entonces podemos simplemente revertir USER_LOCK_BUSY cuando falla ocfs2_dlm_unlock. Corrija user_dlm_cluster_lock(), que es la única función que no sigue esto. [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: desvincular 004fb0000060000b5a90b8c847b72e1, error -16 de la destrucción [ 989.757536] ------------[ cortar aquí ]------------ [ 989.757709] ¡ERROR del kernel en fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] código de operación no válido: 0000 [#1] SMP [ 989.758027] Módulos vinculados en: ksplice_2zhuk2jr_ib_ipoib_new(O) ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf puente stp llc rds_rdma enlace rds ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt soporte de proveedor de iTCO pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [última descarga: ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Contaminado: P OE 4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Nombre del hardware: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 17/06/2021 [ 989.762599] tarea: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[] [] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49339)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL y __init es una mala combinación porque la sección .init.text se libera después de la inicialización. Por lo tanto, los módulos no pueden usar símbolos anotados __init. El acceso a un símbolo liberado puede terminar con un pánico del kernel. modpost solía detectarlo, pero ha estado roto durante una década. Recientemente, arreglé modpost para que comenzara a advertirlo nuevamente, luego esto apareció en las compilaciones de linux-next. Hay dos formas de solucionarlo: - Eliminar __init - Eliminar EXPORT_SYMBOL Elegí esto último para este caso porque el llamador (net/ipv6/seg6.c) y el llamador (net/ipv6/seg6_hmac.c) pertenecen al mismo módulo. Parece una llamada de función interna en ipv6.ko.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49345)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL y __init es una mala combinación porque la sección .init.text se libera después de la inicialización. Por lo tanto, los módulos no pueden usar símbolos anotados __init. El acceso a un símbolo liberado puede terminar con un pánico del kernel. modpost solía detectarlo, pero ha estado roto durante una década. Recientemente, arreglé modpost para que comenzara a advertirlo nuevamente, luego apareció en las compilaciones de linux-next. Hay dos formas de solucionarlo: - Eliminar __init - Eliminar EXPORT_SYMBOL Elegí la última para este caso porque el único sitio de llamada en el árbol, net/ipv4/xfrm4_policy.c nunca se compila como modular. (CONFIG_XFRM es booleano)
-
Vulnerabilidad en kernel de Linux (CVE-2022-49347)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de bug_on en ext4_writepages. Tenemos el siguiente problema: Error EXT4-fs (dispositivo loop0): ext4_mb_generate_buddy:1141: grupo 0, mapa de bits de bloque y descriptor de fondo inconsistentes: 25 frente a 31513 cls libres ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/ext4/inode.c:2708! código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep No contaminado 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 00000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90 Puede suceder de la siguiente manera: 1. escribir inline_data inodo vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> Si el tamaño de los datos en línea es demasiado pequeño, se asignará un bloque para escribir, luego la asignación tendrá una página sucia ext4_da_convert_inline_data_to_extent -> borrar EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> falla irá a restaurar datos ext4_restore_inline_data ext4_crear_inline_data ext4_write_inline_data ext4_set_inode_state -> establecer inodo EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages si (ext4_has_inline_data(inodo)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) La causa principal de este problema es que destruimos los datos en línea hasta que llamamos a ext4_writepages en el modo de asignación de demora. Pero es posible que ya hayamos convertido de en línea a extendido. Para resolver este problema, primero llamamos a filemap_flush.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49350)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL y __init es una mala combinación porque la sección .init.text se libera después de la inicialización. Por lo tanto, los módulos no pueden usar símbolos anotados __init. El acceso a un símbolo liberado puede terminar con un pánico del kernel. modpost solía detectarlo, pero ha estado roto durante una década. Recientemente, arreglé modpost para que comenzara a advertirlo nuevamente, luego apareció en las compilaciones de linux-next. Hay dos formas de solucionarlo: - Eliminar __init - Eliminar EXPORT_SYMBOL Elegí la última para este caso porque el único sitio de llamada en el árbol, drivers/net/phy/phy_device.c nunca se compila como modular. (CONFIG_PHYLIB es booleano)
-
Vulnerabilidad en kernel de Linux (CVE-2022-49379)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: se corrige la interacción wait_for_device_probe() y deferred_probe_timeout El montaje de rootfs NFS se agotaba cuando deferred_probe_timeout no era cero [1]. Esto se debía a que la llamada de inicio ip_auto_config() agotaba el tiempo de espera a que aparecieran las interfaces de red cuando deferred_probe_timeout no era cero. Si bien ip_auto_config() llama a wait_for_device_probe() para asegurarse de que cualquier sonda diferida que se esté ejecutando actualmente funcione o la sonda asincrónica finalice, eso no era suficiente para explicar los dispositivos que se aplazaban hasta deferred_probe_timeout. El commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits Until the deferred_probe_timeout fires") intentó solucionar eso asegurándose de que wait_for_device_probe() espere a que deferred_probe_timeout expire antes de regresar. Sin embargo, si wait_for_device_probe() se llama desde el contexto kernel_init(): - Antes de deferred_probe_initcall() [2], hace que el proceso de arranque se cuelgue debido a un punto muerto. - Después de deferred_probe_initcall() [3], impide que kernel_init() continúe hasta que deferred_probe_timeout expire y supere el punto de deferred_probe_timeout que está tratando de esperar a que el espacio de usuario cargue módulos. Ninguna de estas opciones es buena. Por lo tanto, revierta los cambios a wait_for_device_probe(). [1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/ [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/ [3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/
-
Vulnerabilidad en kernel de Linux (CVE-2022-49397)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: qcom-qmp: corrige pérdida de struct clk en errores de sonda Asegúrese de liberar la referencia del reloj de la tubería en caso de un error de sonda tardío (por ejemplo, aplazamiento de la sonda).
-
Vulnerabilidad en kernel de Linux (CVE-2022-49401)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/page_owner: usar strscpy() en lugar de strlcpy() current->comm[] no es una cadena (no hay garantía de que haya un byte cero en ella). strlcpy(s1, s2, l) está llamando a strlen(s2), lo que podría provocar un acceso fuera de los límites, como informó syzbot: se detectó un desbordamiento de búfer en __fortify_strlen ------------[ corte aquí ]------------ ¡ERROR del kernel en lib/string_helpers.c:980! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 4087 Comm: dhcpcd-run-hooks Not tainted 5.18.0-rc3-syzkaller-01537-g20b87e7c29df #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:fortify_panic+0x18/0x1a lib/string_helpers.c:980 Code: 8c e8 c5 ba e1 fa e9 23 0f bf fa e8 0b 5d 8c f8 eb db 55 48 89 fd e8 e0 49 40 f8 48 89 ee 48 c7 c7 80 f5 26 8a e8 99 09 f1 ff <0f> 0b e8 ca 49 40 f8 48 8b 54 24 18 4c 89 f1 48 c7 c7 00 00 27 8a RSP: 0018:ffffc900000074a8 EFLAGS: 00010286 RAX: 000000000000002c RBX: ffff88801226b728 RCX: 0000000000000000 RDX: ffff8880198e0000 RSI: ffffffff81600458 RDI: fffff52000000e87 RBP: ffffffff89da2aa0 R08: 000000000000002c R09: 0000000000000000 R10: ffffffff815fae2e R11: 0000000000000000 R12: ffff88801226b700 R13: ffff8880198e0830 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5876ad6ff8 CR3: 000000001a48c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: __fortify_strlen include/linux/fortify-string.h:128 [inline] strlcpy include/linux/fortify-string.h:143 [inline] __set_page_owner_handle+0x2b1/0x3e0 mm/page_owner.c:171 __set_page_owner+0x3e/0x50 mm/page_owner.c:190 prep_new_page mm/page_alloc.c:2441 [inline] get_page_from_freelist+0xba2/0x3e00 mm/page_alloc.c:4182 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5408 alloc_pages+0x1aa/0x310 mm/mempolicy.c:2272 alloc_slab_page mm/slub.c:1799 [inline] allocate_slab+0x26c/0x3c0 mm/slub.c:1944 new_slab mm/slub.c:2004 [inline] ___slab_alloc+0x8df/0xf20 mm/slub.c:3005 __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3092 slab_alloc_node mm/slub.c:3183 [inline] slab_alloc mm/slub.c:3225 [inline] __kmem_cache_alloc_lru mm/slub.c:3232 [inline] kmem_cache_alloc+0x360/0x3b0 mm/slub.c:3242 dst_alloc+0x146/0x1f0 net/core/dst.c:92
-
Vulnerabilidad en kernel de Linux (CVE-2022-49407)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dlm: fix plock invalid read Este parche corrige una lectura no válida mostrada por KASAN. Un unlock asignará un "struct plock_op" y un send_op() seguido lo anexará a una estructura de datos global send_list. En algunos casos, un dev_read() seguido lo mueve a recv_list y dev_write() lo convertirá a "struct plock_xop" y accederá a campos que solo están disponibles en esas estructuras. En este punto, se produce una lectura no válida al acceder a esos campos. Para corregir este problema, el campo "callback" se mueve a "struct plock_op" para indicar que se permite una conversión a "plock_xop" y realiza la gestión adicional de "plock_xop" si está configurado. Ejemplo de la salida de KASAN que mostró la lectura no válida: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49409)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige bug_on en __es_tree_search Hulk Robot informó un BUG_ON: ================================================================== kernel BUG at fs/ext4/extents_status.c:199! [...] RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline] RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217 [...] Call Trace: ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 mount_bdev+0x2e9/0x3b0 fs/super.c:1158 mount_fs+0x4b/0x1e4 fs/super.c:1261 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_enable_quotas ext4_quota_enable ext4_iget __ext4_iget ext4_ext_check_inode ext4_ext_check __ext4_ext_check ext4_valid_extent_entries Check for overlapping extents does't take effect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent ext4_es_cache_extent __es_tree_search ext4_es_end BUG_ON(es->es_lblk + es->es_len < es->es_lblk) The error ext4 extents is as follows: 0af3 0300 0400 0000 00000000 extent_header 00000000 0100 0000 12000000 extent1 00000000 0100 0000 18000000 extent2 02000000 0400 0000 14000000 extent3 In the ext4_valid_extent_entries function, if prev is 0, no error is returned even if lblock<=prev.. Esto tenía como objetivo omitir la comprobación de la primera extensión, pero en la imagen de error anterior, prev=0+1-1=0 al comprobar la segunda extensión, por lo que, aunque lblock<=prev, la función no devuelve un error. Como resultado, se produce bug_ON en __es_tree_search y el sistema entra en pánico. Para resolver este problema, solo necesitamos comprobar que: 1. El lblock de la primera extensión no sea menor que 0. 2. El lblock de la siguiente extensión no sea menor que el siguiente bloque de la extensión anterior. Lo mismo se aplica a extended_idx.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49415)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipmi:ipmb: Se corrige la pérdida de recuento de referencias en ipmi_ipmb_probe. of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado; cuando termine, debemos usar of_node_put() en él. Agregue el error of_node_put() faltante para evitar la pérdida de recuento de referencias.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49417)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iwlwifi: mei: soluciona la posible desreferencia de NULL-ptr. Si falla la asignación de SKB, continúa en lugar de usar el puntero NULL. Coverity CID: 1497650
-
Vulnerabilidad en kernel de Linux (CVE-2022-49418)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4: Se corrige el error nfs4_label no inicializado en la búsqueda de referencias. Se envía el fattr ya asignado junto con nfs4_fs_locations y se elimina el memcpy de fattr. Terminamos aumentando dos asignaciones más, pero esto soluciona un fallo como: PID: 790 TAREA: ffff88811b43c000 CPU: 0 COMANDO: "ls" #0 [ffffc90000857920] panic en ffffffff81b9bfde #1 [ffffc900008579c0] do_trap en ffffffff81023a9b #2 [ffffc90000857a10] do_error_trap en ffffffff81023b78 #3 [ffffc90000857a58] exc_stack_segment en ffffffff81be1f45 #4 [ffffc90000857a80] asm_exc_stack_segment en ffffffff81c009de #5 [ffffc90000857b08] nfs_lookup en ffffffffa0302322 [nfs] #6 [ffffc90000857b70] __lookup_slow en ffffffff813a4a5f #7 [ffffc90000857c60] walk_component en ffffffff813a86c4 #8 [ffffc90000857cb8] path_lookupat en ffffffff813a9553 #9 [ffffc90000857cf0] filename_lookup en ffffffff813ab86b
-
Vulnerabilidad en kernel de Linux (CVE-2022-49421)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 22/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: clcdfb: Se corrige la pérdida de recuento de referencias en clcdfb_of_vram_setup of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.



