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 el proceso de inicio de sesión en algunos productos Dahua (CVE-2021-33044)
Severidad: CRÍTICA
Fecha de publicación: 15/09/2021
Fecha de última actualización: 10/11/2025
Una vulnerabilidad de omisión de autenticación de identidad encontrada en algunos productos Dahua durante el proceso de inicio de sesión. Los atacantes pueden omitir la autenticación de la identidad del dispositivo al construir paquetes de datos maliciosos
Vulnerabilidad en kernel de Linux (CVE-2023-53126)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: corrige la pérdida de memoria sas_hba.phy en mpi3mr_remove() Libera mrioc->sas_hba.phy en .remove.
Vulnerabilidad en kernel de Linux (CVE-2023-53127)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Se corrige la pérdida del nodo expansor en mpi3mr_remove(). Se agrega una limpieza de recursos faltantes en .remove.
Vulnerabilidad en kernel de Linux (CVE-2023-53128)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: Se corrige la pérdida de memoria de throttle_groups. Se agrega un kfree() faltante.
Vulnerabilidad en kernel de Linux (CVE-2023-53131)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Se corrige una fuga de información al apagar el servidor. Se corrige una ejecución donde kthread_stop() podría impedir que se llame a threadfn. Si esto ocurre, svc_rqst no se limpiará.
Vulnerabilidad en kernel de Linux (CVE-2023-53132)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: corrige la pérdida de memoria mpi3mr_hba_port en mpi3mr_remove() Libera mpi3mr_hba_port en .remove.
Vulnerabilidad en kernel de Linux (CVE-2023-53133)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: corrige un error de bucle infinito cuando len es 0 en tcp_bpf_recvmsg_parser() Cuando la longitud del búfer de la llamada del sistema recvmsg es 0, tenemos el siguiente problema de bloqueo suave: watchdog: ERROR: bloqueo suave: ¡CPU n.º 3 bloqueada durante 27 s! [a.out:6149] CPU: 3 PID: 6149 Comm: a.out Kdump: cargado No contaminado 6.2.0+ #30 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:remove_wait_queue+0xb/0xc0 Código: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20 RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246 RAX: 000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768 RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040 RBP: 1ffff110236b2f1b R08: 000000000000000 R09: ffff88811a7d37e7 R10: ffffed10234fa6fc R11: 000000000000001 R12: ffff88811179b800 R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0 FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 CR2: 0000000020000000 CR3: 0000000010b6ba002 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: tcp_msg_wait_data+0x279/0x2f0 tcp_bpf_recvmsg_parser+0x3c6/0x490 inet_recvmsg+0x280/0x290 sock_recvmsg+0xfc/0x120 ____sys_recvmsg+0x160/0x3d0 ___sys_recvmsg+0xf0/0x180 __sys_recvmsg+0xea/0x1a0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc The logic in tcp_bpf_recvmsg_parser is as follows: msg_bytes_ready: copied = sk_msg_recvmsg(sk, psock, msg, len, flags); if (!copied) { wait data; goto msg_bytes_ready; } En este caso, "copiado" siempre es 0, se produce el bucle infinito. Según la página del manual de llamadas del sistema de Linux, en este caso se debería devolver 0. Por lo tanto, en tcp_bpf_recvmsg_parser(), si la longitud es 0, se devuelve directamente. Modifique también otras funciones con el mismo problema.
Vulnerabilidad en kernel de Linux (CVE-2023-53134)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Evita la asignación de memoria de orden 5 para datos TPA. El controlador debe registrar todas las posibles finalizaciones simultáneas de TPA (GRO/LRO) en el anillo de agregación. En chips P5, el número máximo de TPA simultáneas es de 256 y la cantidad de memoria que asignamos es de orden 5 en sistemas que utilizan páginas de 4K. Se informó un error de asignación de memoria: NetworkManager: error de asignación de página: orden: 5, modo: 0x40dc0 (GFP_KERNEL | __GFP_COMP | __GFP_ZERO), máscara de nodo = (null), conjunto de CPU = /, mems_allowed = 0-1 CPU: 15 PID: 2995 Comm: NetworkManager Kdump: cargado No contaminado 5.10.156 # 1 Nombre del hardware: Dell Inc. PowerEdge R660 / 0M1CC5, BIOS 0.2.25 12/08/2022 Seguimiento de llamadas: dump_stack + 0x57 / 0x6e warn_alloc.cold.120 + 0x7b / 0xdd ? _cond_resched + 0x15 / 0x30 ? __alloc_pages_direct_compact+0x15f/0x170 __alloc_pages_slowpath.constprop.108+0xc58/0xc70 __alloc_pages_nodemask+0x2d0/0x300 kmalloc_order+0x24/0xe0 kmalloc_order_trace+0x19/0x80 bnxt_alloc_mem+0x1150/0x15c0 [bnxt_es] ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_es] __bnxt_open_nic+0x12e/0x780 [bnxt_es] bnxt_open+0x10b/0x240 [bnxt_es] __dev_open+0xe9/0x180 __dev_change_flags+0x1af/0x220 dev_change_flags+0x21/0x60 do_setlink+0x35c/0x1100 En lugar de asignar esta gran cantidad de memoria y dividirla para las instancias de TPA simultáneas, asigne cada pequeña cantidad por separado para cada instancia de TPA. Esto reducirá las asignaciones a un orden de 0.
Vulnerabilidad en kernel de Linux (CVE-2023-53135)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: Usar READ_ONCE_NOCHECK en modo de desenrollado de pila impreciso Cuando no se establece CONFIG_FRAME_POINTER, la función de desenrollado de pila walk_stackframe lee la pila aleatoriamente y luego, cuando KASAN está habilitado, puede llevar al siguiente backtrace: [ 0.000000] ===================================================================== [ 0.000000] ERROR: KASAN: pila fuera de los límites en walk_stackframe+0xa6/0x11a [ 0.000000] Lectura de tamaño 8 en la dirección ffffffff81807c40 por tarea swapper/0 [ 0.000000] [ 0.000000] CPU: 0 PID: 0 Comm: swapper No contaminado 6.2.0-12919-g24203e6db61f #43 [ 0.000000] Nombre del hardware: riscv-virtio,qemu (DT) [ 0.000000] Rastreo de llamadas: [ 0.000000] [] walk_stackframe+0x0/0x11a [ 0.000000] [] init_param_lock+0x26/0x2a [ 0.000000] [] walk_stackframe+0xa2/0x11a [ 0.000000] [] dump_stack_lvl+0x22/0x36 [ 0.000000] [] print_report+0x198/0x4a8 [ 0.000000] [] init_param_lock+0x26/0x2a [ 0.000000] [] walk_stackframe+0xa2/0x11a [ 0.000000] [] kasan_report+0x9a/0xc8 [ 0.000000] [] walk_stackframe+0xa2/0x11a [ 0.000000] [] walk_stackframe+0xa2/0x11a [ 0.000000] [] desc_make_final+0x80/0x84 [ 0.000000] [] stack_trace_save+0x88/0xa6 [ 0.000000] [] filter_irq_stacks+0x72/0x76 [ 0.000000] [] devkmsg_read+0x32a/0x32e [ 0.000000] [] kasan_save_stack+0x28/0x52 [ 0.000000] [] desc_make_final+0x7c/0x84 [ 0.000000] [] stack_trace_save+0x84/0xa6 [ 0.000000] [] kasan_set_track+0x12/0x20 [ 0.000000] [] __kasan_slab_alloc+0x58/0x5e [ 0.000000] [] __kmem_cache_create+0x21e/0x39a [ 0.000000] [] create_boot_cache+0x70/0x9c [ 0.000000] [] kmem_cache_init+0x6c/0x11e [ 0.000000] [] mm_init+0xd8/0xfe [ 0.000000] [] start_kernel+0x190/0x3ca [ 0.000000] [ 0.000000] The buggy address belongs to stack of task swapper/0 [ 0.000000] and is located at offset 0 in frame: [ 0.000000] stack_trace_save+0x0/0xa6 [ 0.000000] [ 0.000000] This frame has 1 object: [ 0.000000] [32, 56) 'c' [ 0.000000] [ 0.000000] The buggy address belongs to the physical page: [ 0.000000] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81a07 [ 0.000000] flags: 0x1000(reserved|zone=0) [ 0.000000] raw: 0000000000001000 ff600003f1e3d150 ff600003f1e3d150 0000000000000000 [ 0.000000] raw: 0000000000000000 0000000000000000 00000001ffffffff [ 0.000000] page dumped because: kasan: bad access detected [ 0.000000] [ 0.000000] Memory state around the buggy address: [ 0.000000] ffffffff81807b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] ffffffff81807b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] >ffffffff81807c00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3 [ 0.000000] ^ [ 0.000000] ffffffff81807c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] ffffffff81807d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] ================================================================== Solucione esto usando READ_ONCE_NOCHECK al leer la pila en modo impreciso.
Vulnerabilidad en kernel de Linux (CVE-2023-53136)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: se corrigen fugas de struct pid en la compatibilidad OOB. syzbot reportó una fuga de struct pid [1]. El problema radica en que queue_oob() llama a perhaps_add_creds(), que potencialmente contiene una referencia a un PID. Sin embargo, skb->destructor no está definido (ni directamente ni mediante la llamada a unix_scm_to_skb()). Esto significa que las posteriores operaciones kfree_skb() o consume_skb() filtrarían esta referencia. En esta corrección, opté por ofrecer compatibilidad total con scm, incluso para el mensaje OOB. [1] ERROR: pérdida de memoria, objeto no referenciado 0xffff8881053e7f80 (tamaño 128): comunicación "syz-executor242", pid 5066, jiffies 4294946079 (edad 13.220s), volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] alloc_pid+0x6a/0x560 kernel/pid.c:180 [] copy_process+0x169f/0x26c0 kernel/fork.c:2285 [] kernel_clone+0xf7/0x610 kernel/fork.c:2684 [] __do_sys_clone+0x7c/0xb0 kernel/fork.c:2825 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Vulnerabilidad en kernel de Linux (CVE-2023-53138)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: caif: Se corrige el use-after-free en cfusbl_device_notify() syzbot informó el use-after-free en cfusbl_device_notify() [1]. Esto provoca un seguimiento de pila como el siguiente: ERROR: KASAN: use-after-free en cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 Lectura de tamaño 8 en la dirección ffff88807ac4e6f0 por la tarea kworker/u4:6/1214 CPU: 0 PID: 1214 Comm: kworker/u4:6 No contaminado 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Cola de trabajo: netns cleanup_net Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 notifier_call_chain+0xb5/0x200 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10227 [inline] netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341 default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334 ops_exit_list+0x125/0x170 net/core/net_namespace.c:167 cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 Al anular el registro de un dispositivo de red, unregister_netdevice_many_notify() establece el estado del dispositivo en NETREG_UNREGISTERING, llama a los notificadores con NETDEV_UNREGISTER y añade el dispositivo a la lista de tareas pendientes. Posteriormente, netdev_run_todo() procesa los dispositivos de la lista de tareas pendientes. netdev_run_todo() espera a que el recuento de referencias de los dispositivos llegue a 1 mientras retransmite la notificación NETDEV_UNREGISTER. Si se llama a cfusbl_device_notify() con NETDEV_UNREGISTER varias veces, el dispositivo principal podría liberarse. Esto podría causar un UAF. Procesar NETDEV_UNREGISTER varias veces también provoca un desequilibrio en el recuento de referencias del módulo. Este parche soluciona el problema aceptando solo la primera notificación NETDEV_UNREGISTER.
Vulnerabilidad en kernel de Linux (CVE-2023-53139)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: fdp: agregar comprobación nula de devm_kmalloc_array en fdp_nci_i2c_read_device_properties devm_kmalloc_array puede fallar, *fw_vsc_cfg puede ser nulo y provocar una escritura fuera de los límites en device_property_read_u8_array más adelante.
Vulnerabilidad en kernel de Linux (CVE-2023-53140)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: Eliminar el directorio /proc/scsi/${proc_name} antes. Eliminar el directorio /proc/scsi/${proc_name} antes para corregir una condición de ejecución entre la descarga y la recarga de módulos del kernel. Esto corrige un error introducido en 2009 por el commit 77c019768f06 ("[SCSI] corregir fuga de memoria de /proc en el núcleo SCSI"). Corrija la siguiente advertencia del kernel: proc_dir_entry 'scsi/scsi_debug' ya está registrado ADVERTENCIA: CPU: 19 PID: 27986 en fs/proc/generic.c:376 proc_register+0x27d/0x2e0 Seguimiento de llamadas: proc_mkdir+0xb5/0xe0 scsi_proc_hostdir_add+0xb5/0x170 scsi_host_alloc+0x683/0x6c0 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug] really_probe+0x159/0x540 __driver_probe_device+0xdc/0x230 driver_probe_device+0x4f/0x120 __device_attach_driver+0xef/0x180 bus_for_each_drv+0xe5/0x130 __device_attach+0x127/0x290 device_initial_probe+0x17/0x20 bus_probe_device+0x110/0x130 device_add+0x673/0xc80 device_register+0x1e/0x30 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug] scsi_debug_init+0x64f/0x1000 [scsi_debug] do_one_initcall+0xd7/0x470 do_init_module+0xe7/0x330 load_module+0x122a/0x12c0 __do_sys_finit_module+0x124/0x1a0 __x64_sys_finit_module+0x46/0x50 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
Vulnerabilidad en kernel de Linux (CVE-2023-53141)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ila: no generar mensajes vacíos en ila_xlat_nl_cmd_get_mapping(). ila_xlat_nl_cmd_get_mapping() genera un skb vacío, lo que activa una comprobación de integridad reciente [1]. En su lugar, devuelve un código de error para que el espacio de usuario pueda obtenerlo. [1] skb_assert_len ADVERTENCIA: CPU: 0 PID: 5923 en include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [en línea] ADVERTENCIA: CPU: 0 PID: 5923 en include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 Módulos vinculados: CPU: 0 PID: 5923 Comm: syz-executor269 No contaminado 6.2.0-syzkaller-18300-g2ebd1fbb946d #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 21/01/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_assert_len include/linux/skbuff.h:2527 [en línea] pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 lr : skb_assert_len include/linux/skbuff.h:2527 [en línea] lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 sp : ffff80001e0d6c40 x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0 x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00 x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10 x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0 x17: 000000000000000 x16: ffff80001235d16c x15: 000000000000000 x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001 x11: ff80800008353a30 x10: 0000000000000000 x9: 21567eaf25bfb600 x8: 21567eaf25bfb600 x7: 000000000000001 x6: 000000000000001 x5: ffff80001e0d6558 x4: ffff800015c74760 x3: ffff800008596744 x2: 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e Rastreo de llamadas: skb_assert_len include/linux/skbuff.h:2527 [en línea] __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156 dev_queue_xmit include/linux/netdevice.h:3033 [en línea] __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [en línea] __netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325 netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1283 [en línea] netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292 netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380 nlmsg_unicast include/net/netlink.h:1099 [en línea] genlmsg_unicast include/net/genetlink.h:433 [en línea] genlmsg_reply include/net/genetlink.h:443 [en línea] ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [en línea] genl_family_rcv_msg net/netlink/genetlink.c:1048 [en línea] genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065 netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574 genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [en línea] netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] ____sys_sendmsg+0x558/0x844 net/socket.c:2479 ___sys_sendmsg net/socket.c:2533 [en línea] __sys_sendmsg+0x26c/0x33c net/socket.c:2562 __do_sys_sendmsg net/socket.c:2571 [en línea] __se_sys_sendmsg net/socket.c:2569 [en línea] __arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569 __invoke_syscall arch/arm64/kernel/syscall.c:38 [en línea] invocar_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52 el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193 el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 marca de evento irq: 136484 hardirqs habilitados por última vez en (136483): [] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345 hardirqs deshabilitados por última vez en (136484): [] el1_dbg+0x24/0x80 arch/arm6 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2023-53142)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: se omite la copia del último bloque en ice_get_module_eeprom(). ice_get_module_eeprom() no funciona desde el commit e9c9692c8a81 ("ice: Reimplementar las lecturas del módulo utilizadas por ethtool"). En esta refactorización, ice_get_module_eeprom() lee la EEPROM en bloques de tamaño 8. Sin embargo, la condición que debería proteger contra el desbordamiento del búfer ignora el último bloque. Este último bloque siempre contiene ceros. Error descubierto por el commit upstream de ethtool 9538f384b535 ("netlink: eeprom: Aplazar las solicitudes de página a analizadores individuales"). Después de esta confirmación, ethtool lee un bloque con longitud = 1; para leer el valor del identificador SFF-8024. controlador sin parchear: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Valores de desplazamiento ------ ------ 0x0090: 00 00 00 00 00 00 00 00 $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Valores de desplazamiento ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 00 00 00 00 $ $ ethtool -m enp65s0f0np0 Valores de desplazamiento ------ ------ 0x0000: 11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00 0x0070: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 controlador parcheado: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Valores de desplazamiento ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Valores de desplazamiento ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 61 6e 6f 78 $ ethtool -m enp65s0f0np0 Identificador: 0x11 (QSFP28) Identificador extendido: 0x00 Descripción del identificador extendido: 1,5 W máx. Consumo de energía Descripción extendida del identificador: Sin CDR en TX, Sin CDR en RX Descripción extendida del identificador: Clase de alta potencia (> 3,5 W) no habilitada Conector: 0x23 (sin conector separable) Códigos del transceptor: 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Tipo de transceptor: Ethernet de 40 G: Base-CR4 de 40 G Tipo de transceptor: Ethernet de 25 G: Base-CR de 25 G Codificación CA-N: 0x05 (64B/66B) BR, nominal: 25500 Mbps Identificador de velocidad: 0x00 Longitud (SMF, km): 0 km Longitud (OM3 50 um): 0 m Longitud (OM2 50 um): 0 m Longitud (OM1 62,5 um): 0 m Longitud (cobre o cable activo): 1m Tecnología del transmisor: 0xa0 (cable de cobre sin ecualizar) Atenuación a 2,5 GHz: 4 db Atenuación a 5,0 GHz: 5 db Atenuación a 7,0 GHz: 7 db Atenuación a 12,9 GHz: 10 db ........ ....
Vulnerabilidad en kernel de Linux (CVE-2023-53143)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige otro error de fsmap de un bloque en sistemas de archivos de 1k Aparentemente, syzbot descubrió que emitir esta llamada FSMAP: Produce este fallo si el sistema de archivos subyacente es un sistema de archivos ext4 de 1k bloques: ¡ERROR del kernel en fs/ext4/ext4.h:3331! Código de operación no válido: 0000 [#1] PREEMPT SMP CPU: 3 PID: 3227965 Comm: xfs_io Contaminado: GWO 6.2.0-rc8-achx Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 01/04/2014 RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4] RSP: 0018:ffffc90007c03998 EFLAGS: 00010246 RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000 RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11 RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400 R10: ffffc90007c03950 R11: 0000000000000000 R12: 000000000000001 R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398 FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0 Rastreo de llamadas: ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __x64_sys_ioctl+0x82/0xa0 hacer_llamada_al_sistema_64+0x2b/0x80 entrada_LLAMADA_AL_SISTEMA_64_después_de_hwframe+0x46/0xb0 RIP: 0033:0x7fdf20558aff RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003 RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010 R13: 00005625be70d994 R14: 000000000000800 R15: 000000000000000 Para las llamadas GETFSMAP, el llamador selecciona un dispositivo de bloque físico escribiendo su número de bloque en fsmap_head.fmh_keys[01].fmr_device. Para consultar las asignaciones de un subrango del dispositivo, el byte inicial del rango se escribe en fsmap_head.fmh_keys[0].fmr_physical y el último byte en fsmap_head.fmh_keys[1].fmr_physical. IOWs, para consultar qué asignaciones se superponen con los bytes 3-14 de /dev/sda, debe configurar las entradas de la siguiente manera: fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3}, fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14}, lo que le devolvería lo que esté asignado en los 12 bytes a partir del desplazamiento físico 3. El fallo se debe a una validación de rango insuficiente de keys[1] en ext4_getfsmap_datadev. En sistemas de archivos de 1k bloques, el bloque 0 no forma parte del sistema de archivos, lo que significa que s_first_data_block es distinto de cero. ext4_get_group_no_and_offset resta esta cantidad del argumento blocknr antes de descomponerlo en un número de grupo y un número de bloque dentro de un grupo. En las IOW, el grupo de bloques 0 abarca los bloques 1-8192 (basado en 1) en lugar de 0-8191 (basado en 0), como ocurre con tamaños de bloque mayores. El resultado final de esta codificación es que blocknr < s_first_data_block no es una entrada válida para esta función. La variable end_fsb se establece a partir de las claves copiadas del espacio de usuario, lo que significa que, en el ejemplo anterior, su valor es cero. Esto genera un desbordamiento por debajo de la capacidad: blocknr = blocknr - le32_to_cpu(es->s_first_data_block); La división opera entonces sobre -1: offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >> EXT4_SB(sb)->s_cluster_bits; De esta manera, se deja un número de grupo imposiblemente grande (2^32-1) en blocknr. ext4_getfsmap_check_keys verificó que keys[0 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2023-53144)
Severidad: MEDIA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige kunmap incorrecto al usar LZMA en plataformas HIGHMEM Como lo muestra el seguimiento de llamadas, la causa raíz son páginas incorrectas de kunmap: ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000 CPU: 1 PID: 40 Comm: kworker/u5:0 No contaminado 6.2.0-rc5 #4 Cola de trabajo: erofs_worker z_erofs_decompressqueue_work EIP: z_erofs_lzma_decompress+0x34b/0x8ac z_erofs_decompress+0x12/0x14 z_erofs_decompress_queue+0x7e7/0xb1c z_erofs_decompressqueue_work+0x32/0x60 process_one_work+0x24b/0x4d8 ? process_one_work+0x1a4/0x4d8, work_thread+0x14c/0x3fc, kthread+0xe6/0x10c, rescuer_thread+0x358/0x358, kthread_complete_and_exit+0x18/0x18, ret_from_fork+0x1c/0x28 ---[ fin del seguimiento 000000000000000 ]--- El error es trivial y debería estar corregido. No afecta a las plataformas !HIGHMEM.
Vulnerabilidad en Oracle (CVE-2022-21546)
Severidad: ALTA
Fecha de publicación: 02/05/2025
Fecha de última actualización: 10/11/2025
En versiones más recientes de las especificaciones de SBC, tenemos un bit NDOB que indica que no hay búfer de datos que se escriba. Si este bit se activa mediante comandos como "sg_write_same --ndob", se producirá un fallo en los controladores "execute_write_same" de target_core_iblock/file al acceder a se_cmd->t_data_sg, ya que es nulo. Puntuación base de CVSS 3.1: 7.7 (Afecta a la disponibilidad). Vector CVSS: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H).
Vulnerabilidad en kernel de Linux (CVE-2025-37799)
Severidad: MEDIA
Fecha de publicación: 03/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vmxnet3: Se ha corregido un tamaño de paquete incorrecto en vmxnet3_process_xdp. El manejo de XDP del controlador vmxnet3 presenta errores para tamaños de paquete que utilizan ring0 (es decir, tamaños de paquete entre 128 y 3 k bytes). Observamos problemas de conectividad relacionados con la MTU con el balanceo de carga del servicio de Cilium en el caso de vmxnet3 como NIC subyacente. Una simple conexión curl a un servicio HTTP backend donde el LB XDP realizaba encapsulado IPIP generó tamaños de paquete excesivamente grandes, pero solo para *algunos* paquetes (p. ej., una solicitud HTTP GET), mientras que otros (p. ej., el TCP 3WHS anterior) funcionaron correctamente en la red. De hecho, la grabación de pcap en el nodo backend reveló que el nodo con el LB XDP estaba filtrando datos de kernel sin inicializar en la red para los paquetes afectados. Por ejemplo, si bien los paquetes deberían haber tenido 152 bytes, su tamaño real era de 1482 bytes, por lo que el resto después de 152 bytes se rellenó con cualquier otro dato que hubiera en esa página en ese momento (por ejemplo, vimos datos de usuario/carga útil de paquetes procesados previamente). Solo notamos esto a través de un problema de MTU; por ejemplo, cuando el nodo LB XDP y el nodo backend tenían la misma MTU (por ejemplo, 1500), la solicitud curl se descartó en la NIC del nodo backend debido a que el paquete era demasiado grande, aunque el paquete encapsulado en IPIP normalmente ni siquiera se acercaría al límite de MTU. Reducir la MTU en el LB XDP (por ejemplo, 1480) permitió que la solicitud curl se ejecutara correctamente (lo que también indica que el kernel ignoró el relleno y, por lo tanto, el problema no era muy visible para el usuario). el commit e127ce7699c1 ("vmxnet3: Corrección de la falta de espacio reservado para la cola") estaba demasiado ansiosa por cambiar xdp_prepare_buff() de rcd->len a rbi->len. Es necesario que se mantenga en rcd->len, que es la longitud real del paquete del descriptor. Por cierto, esta última también se introduce en vmxnet3_process_xdp_small(), e indica la longitud correcta necesaria para inicializar las partes xdp->{data,data_end}. Para e127ce7699c1 ("vmxnet3: Corrección de la falta de espacio reservado para la cola"), la parte relevante fue adaptar xdp_init_buff() para abordar la advertencia, dado que xdp_data_hard_end() depende de xdp->frame_sz. Con esto corregido, el tráfico en la red se ve bien de nuevo.
Vulnerabilidad en kernel de Linux (CVE-2024-58098)
Severidad: MEDIA
Fecha de publicación: 05/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: propiedad `track changes_pkt_data` para funciones globales. Al procesar llamadas a ciertos ayudantes, el verificador invalida todos los punteros de paquete en un estado actual. Por ejemplo, considere el siguiente programa: __attribute__((__noinline__)) long skb_pull_data(struct __sk_buff *sk, __u32 len) { return bpf_skb_pull_data(sk, len); } SEC("tc") int test_invalidate_checks(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP; skb_pull_data(sk, 0); *p = 42; return TCX_PASS; Tras una llamada a bpf_skb_pull_data(), el puntero 'p' no se puede usar de forma segura. Consulte la función filter.c:bpf_helper_changes_pkt_data() para obtener una lista de dichos ayudantes. Actualmente, el verificador invalida los punteros de paquetes al procesar llamadas a funciones de ayuda y no recorre subprogramas globales al procesar llamadas a subprogramas globales. Esto significa que las llamadas a ayudantes realizadas desde subprogramas globales no invalidan los punteros en el estado del llamador. Por ejemplo, el programa anterior es inseguro, pero no es rechazado por el verificador. Esta confirmación corrige la omisión calculando el campo bpf_subprog_info->changes_pkt_data para cada subprograma antes de la verificación principal. changes_pkt_data debe establecerse si: - el subprograma llama a un ayudante para el cual bpf_helper_changes_pkt_data devuelve verdadero; - el subprograma llama a una función global, para la cual bpf_subprog_info->changes_pkt_data debe establecerse. El pase verifier.c:check_cfg() se modifica para calcular esta información. el commit se basa en el recorrido de la instrucción de profundidad primero realizado por check_cfg() y la ausencia de llamadas a funciones recursivas: - check_cfg() eventualmente visitaría cada llamada al subprograma S en un estado cuando S está completamente explorado; - cuando S está completamente explorado: - cada llamada de ayuda directa dentro de S es explorada (y por lo tanto changes_pkt_data se establece si es necesario); - cada llamada al subprograma S1 llamada por S fue visitada con S1 completamente explorado (y por lo tanto S hereda changes_pkt_data de S1). La desventaja de este enfoque es que no se tiene en cuenta la eliminación de código muerto: si una llamada de ayuda dentro de una función global está muerta debido a la configuración actual, el verificador asumiría conservadoramente que la llamada ocurre para el propósito del cálculo de changes_pkt_data.
Vulnerabilidad en kernel de Linux (CVE-2024-58100)
Severidad: MEDIA
Fecha de publicación: 05/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: comprobar la propiedad changes_pkt_data para programas de extensión Al procesar llamadas a subprogramas globales, el verificador decide si invalidar todos los punteros de paquete en el estado actual dependiendo de la propiedad changes_pkt_data del subprograma global. Debido a esto, un programa de extensión que reemplaza un subprograma global debe ser compatible con la propiedad changes_pkt_data del subprograma que se está reemplazando. Esta confirmación: - añade el indicador changes_pkt_data a struct bpf_prog_aux: - este indicador se establece en check_cfg() para el subprograma principal; - en jit_subprogs() para otros subprogramas; - modifica bpf_check_attach_btf_id() para comprobar el indicador changes_pkt_data; - mueve la llamada a check_attach_btf_id() después de la llamada a check_cfg(), porque necesita que se configure el indicador changes_pkt_data: bpf_check: ... ... - check_attach_btf_id resolve_pseudo_ldimm64 resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded bpf_prog_is_offloaded check_cfg check_cfg + check_attach_btf_id ... ... Los siguientes campos se configuran mediante check_attach_btf_id(): - env->ops - prog->aux->attach_btf_trace - prog->aux->attach_func_name - prog->aux->attach_func_proto - prog->aux->dst_trampoline - prog->aux->mod - prog->aux->saved_dst_attach_type - prog->aux->saved_dst_prog_type - prog->expected_attach_type Ninguno de estos campos es utilizado por resolve_pseudo_ldimm64() o bpf_prog_offload_verifier_prep() (para los controladores netronome y netdevsim), por lo que el reordenamiento es seguro.
Vulnerabilidad en kernel de Linux (CVE-2024-58237)
Severidad: MEDIA
Fecha de publicación: 05/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: considerar que las llamadas de cola invalidan los punteros de paquete. Los programas con llamadas de cola podrían ejecutar cualquiera de los ayudantes que invalidan los punteros de paquete. Por lo tanto, se asume, de forma conservadora, que cada llamada de cola invalida los punteros de paquete. Al realizar el cambio en bpf_helper_changes_pkt_data(), se utiliza automáticamente la lógica check_cfg(), que calcula el efecto de 'changes_pkt_data' para los subprogramas globales, de modo que el siguiente programa podría ser rechazado: int tail_call(struct __sk_buff *sk) { bpf_tail_call_static(sk, &jmp_table, 0); return 0; } SEC("tc") int not_safe(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; ... make p valid ... tail_call(sk); *p = 42; /* esto no es seguro */ ... } La función tc_bpf2bpf.c:subprog_tc() debe modificarse: márquela como una función que puede invalidar punteros de paquetes. De lo contrario, no se puede reemplazar con tailcall_freplace.c:entry_freplace(), que realiza una llamada de cola.
Vulnerabilidad en kernel de Linux (CVE-2020-36791)
Severidad: ALTA
Fecha de publicación: 07/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: mantener alloc_hash actualizado tras la asignación de hash. En el commit 599be01ee567 ("net_sched: corregir un acceso OOB en cls_tcindex"), se movió el cálculo de cp->hash antes del primer tcindex_alloc_perfect_hash(), pero se mantuvo intacto. Esta diferencia podría provocar otro acceso fuera de los límites. cp->alloc_hash siempre debe tener el tamaño asignado; debemos actualizarlo después de este tcindex_alloc_perfect_hash().
Vulnerabilidad en kernel de Linux (CVE-2025-37806)
Severidad: MEDIA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Mantener las operaciones de escritura atómicas. syzbot reportó una desreferencia de puntero nulo en __generic_file_write_iter. [1] Antes de completar la operación de escritura, el usuario ejecuta ioctl[2] para borrar el indicador de compresión del archivo, lo que provoca que la sentencia is_compressed() devuelva 0, lo que provoca que el programa acceda al proceso incorrecto y llame a la operación incorrecta ntfs_aops_cmpr, lo que desencadena la desreferencia de puntero nulo de write_begin. Utilice el bloqueo de inodo para sincronizar ioctl y write y evitar este caso. [1] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 Información de aborto de memoria: ESR = 0x0000000086000006 EC = 0x21: IABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: error de traducción de nivel 2 usuario pgtable: 4k páginas, VAs de 48 bits, pgdp=000000011896d000 [000000000000000] pgd=0800000118b44403, p4d=0800000118b44403, pud=0800000117517403, pmd=0000000000000000 Error interno: Oops: 0000000086000006 [#1] PREEMPT Módulos SMP vinculados: CPU: 0 UID: 0 PID: 6427 Comm: syz-executor347 No contaminado 6.13.0-rc3-syzkaller-g573067a5a685 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : generic_perform_write+0x29c/0x868 mm/filemap.c:4055 sp : ffff80009d4978a0 x29: ffff80009d4979c0 x28: dfff800000000000 x27: ffff80009d497bc8 x26: 00000000000000000 x25: ffff80009d497960 x24: ffff80008ba71c68 x23: 0000000000000000 x22: ffff0000c655dac0 x21: 0000000000001000 x20: 0000000000000000c x19: 1ffff00013a92f2c x18: ffff0000e183aa1c x17: 0004060000000014 x16: ffff800083275834 x15: 0000000000000001 x14: 0000000000000000 x13: 0000000000000001 x12: ffff0000c655dac0 x11: 0000000000ff0100 x10: 0000000000ff0100 x9: 0000000000000000 x8: 0000000000000000 x7: 0000000000000000 x6: 0000000000000000 x5 : ffff80009d497980 x4 : ffff80009d497960 x3 : 0000000000001000 x2 : 0000000000000000 x1 : ffff0000e183a928 x0 : ffff0000d60b0fc0 Rastreo de llamada: 0x0 (P) __generic_file_write_iter+0xfc/0x204 mm/filemap.c:4156 ntfs_file_write_iter+0x54c/0x630 fs/ntfs3/file.c:1267 new_sync_write fs/read_write.c:586 [inline] vfs_write+0x920/0xcf4 fs/read_write.c:679 ksys_write+0x15c/0x26c fs/read_write.c:731 __do_sys_write fs/read_write.c:742 [inline] __se_sys_write fs/read_write.c:739 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 [2] ioctl$FS_IOC_SETFLAGS(r0, 0x40086602, &(0x7f00000000c0)=0x20)
Vulnerabilidad en kernel de Linux (CVE-2025-37807)
Severidad: MEDIA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige la advertencia de kmemleak para el mapa hash de percpu Vlad Poenaru informó el siguiente problema de kmemleak: objeto sin referencia 0x606fd7c44ac8 (tamaño 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Una investigación más profunda muestra que la razón se debe a un almacenamiento no alineado de 8 bytes del puntero por CPU en htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Tenga en cuenta que la alineación completa de htab_elem es 8 (para x86_64). Si key_size es 4, significa que pptr se almacena en una ubicación que está alineada con 4 bytes pero no con 8 bytes. En mm/kmemleak.c, scan_block() escanea la memoria basándose en un paso de 8 bytes, por lo que no detectará por encima de pptr, por lo que informa la pérdida de memoria. En htab_map_alloc(), ya tenemos htab->elem_size = sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->elem_size += round_up(htab->map.value_size, 8); Por lo tanto, almacenar pptr con alineación de 8 bytes no causará ningún problema y también puede solucionar la fuga de kmem. El problema también se puede reproducir con la autoprueba de BPF: 1. Habilite la configuración CONFIG_DEBUG_KMEMLEAK. 2. Añada un getchar() antes de skel destroy en test_hash_map() en prog_tests/for_each.c. El objetivo es mantener el mapa disponible para que se pueda detectar la fuga de kmem. 3. Ejecute './test_progs -t for_each/hash_map &' y se debería informar de una fuga de kmem.
Vulnerabilidad en kernel de Linux (CVE-2025-37808)
Severidad: MEDIA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: null - Utilizar bloqueo de giro en lugar de mutex Como el algoritmo nulo se puede liberar en el contexto de softirq a través de af_alg, utilice bloqueos de giro en lugar de mutex para proteger el algoritmo nulo predeterminado.
Vulnerabilidad en kernel de Linux (CVE-2025-37822)
Severidad: ALTA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: uprobes: Añadir un archivo "fence.i" faltante tras la construcción del búfer XOL. El búfer XOL (ejecución fuera de línea) se utiliza para ejecutar paso a paso las instrucciones reemplazadas para uprobes. El puerto RISC-V carecía de un archivo "fence.i" adecuado (vaciado de i$) tras la construcción del búfer XOL, lo que puede provocar la ejecución incorrecta de instrucciones obsoletas o dañadas. Esto se detectó al ejecutar las pruebas automáticas de BPF "test_progs: uprobe_autoattach, attached_probe" en Spacemit K1/X60, donde las pruebas de uprobes fallaron aleatoriamente.
Vulnerabilidad en kernel de Linux (CVE-2025-37823)
Severidad: ALTA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: hfsc: Se corrige también un posible UAF en hfsc_dequeue(). Al igual que en el parche anterior, también debemos proteger hfsc_dequeue(). Sin embargo, para este caso, no contamos con un reproductor fiable.
Vulnerabilidad en kernel de Linux (CVE-2025-37824)
Severidad: MEDIA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrige la desreferencia del puntero NULL en tipc_mon_reinit_self() syzbot informó: tipc: Número de nodo establecido en 1055423674 Oops: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 No contaminado 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Nombre del hardware: QEMU PC estándar (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Cola de trabajo: eventos tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [en línea] subproceso_de_trabajo+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_de_bifurcación+0x45/0x80 arch/x86/kernel/process.c:153 ret_de_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 00000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Hay una condición de ejecución entre la cola de trabajo creada al habilitar el portador y otro hilo creado al deshabilitar el portador justo después de eso, como se muestra a continuación: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-37825)
Severidad: ALTA
Fecha de publicación: 08/05/2025
Fecha de última actualización: 10/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: se corrige el acceso fuera de los límites en nvmet_enable_port Al intentar habilitar un puerto que aún no tiene transporte configurado, nvmet_enable_port() usa NVMF_TRTYPE_MAX (255) para consultar la matriz de transportes, lo que provoca un acceso fuera de los límites: [ 106.058694] ERROR: KASAN: global fuera de los límites en nvmet_enable_port+0x42/0x1da [ 106.058719] Lectura de tamaño 8 en la dirección ffffffff89dafa58 por la tarea ln/632 [...] [ 106.076026] nvmet: no se admite el tipo de transporte 255 Desde la confirmación 200adac75888, NVMF_TRTYPE_MAX es el estado predeterminado según la configuración de nvmet_ports_make(). Evite esto verificando NVMF_TRTYPE_MAX antes de continuar.
Vulnerabilidad en Dígitro NGC Explorer 3.44.15 (CVE-2025-4526)
Severidad: MEDIA
Fecha de publicación: 11/05/2025
Fecha de última actualización: 10/11/2025
Se encontró una vulnerabilidad clasificada como problemática en Dígitro NGC Explorer 3.44.15. Esta afecta a una parte desconocida de la página de configuración del componente. La manipulación provoca la omisión del enmascaramiento del campo de contraseña. Es posible iniciar el ataque puede ejecutarse en remoto. Se contactó al proveedor con antelación para informarle sobre esta vulnerabilidad, pero no respondió.
Vulnerabilidad en Dígitro NGC Explorer (CVE-2025-4527)
Severidad: MEDIA
Fecha de publicación: 11/05/2025
Fecha de última actualización: 10/11/2025
Se ha detectado una vulnerabilidad en Dígitro NGC Explorer 3.44.15, clasificada como problemática. Esta vulnerabilidad afecta al código desconocido del componente "Password Transmission Handler". La manipulación permite la aplicación de la seguridad del servidor por parte del cliente. El ataque puede ejecutarse en remoto. Es un ataque de complejidad bastante alta. Parece difícil de explotar. Se contactó al proveedor con antelación para informarle sobre esta revelación, pero no respondió.
Vulnerabilidad en Dígitro NGC Explorer (CVE-2025-4528)
Severidad: MEDIA
Fecha de publicación: 11/05/2025
Fecha de última actualización: 10/11/2025
Se encontró una vulnerabilidad en Dígitro NGC Explorer hasta la versión 3.44.15, clasificada como problemática. Este problema afecta a algunos procesos desconocidos. La manipulación provoca la expiración de la sesión. El ataque podría iniciarse remotamente. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en ContiNew Admin (CVE-2025-4551)
Severidad: MEDIA
Fecha de publicación: 11/05/2025
Fecha de última actualización: 10/11/2025
Se encontró una vulnerabilidad clasificada como problemática en ContiNew Admin hasta la versión 3.6.0. La vulnerabilidad afecta a una función desconocida del archivo /dev-api/common/file. La manipulación del argumento "File" provoca ataques de cross site scripting. Es posible ejecutar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en ContiNew Admin (CVE-2025-4552)
Severidad: MEDIA
Fecha de publicación: 12/05/2025
Fecha de última actualización: 10/11/2025
Se ha detectado una vulnerabilidad en ContiNew Admin hasta la versión 3.6.0, clasificada como problemática. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /dev-api/system/user/1/password. La manipulación provoca un cambio de contraseña no verificado. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
Vulnerabilidad en gongfuxiang schoolcms 2.3.1 (CVE-2025-4795)
Severidad: MEDIA
Fecha de publicación: 16/05/2025
Fecha de última actualización: 10/11/2025
Se ha detectado una vulnerabilidad crítica en gongfuxiang schoolcms 2.3.1. Esta afecta a la función SaveInfo del archivo /index.php?m=Admin&c=article&a=SaveInfo. La manipulación del ID del argumento provoca una inyección SQL. Es posible iniciar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado.