Vulnerabilidades

El complemento Magical Addons For Elementor para WordPress es vulnerable a la exposición de información confidencial en todas las versiones hasta la 1.2.4 incluida a través de la función get_content_type en features/widgets/content-reveal.php. Esto permite que atacantes autenticados, con acceso de nivel de colaborador y superior, extraigan datos confidenciales de plantillas privadas, pendientes y en borrador.

El complemento FOX – Currency Switcher Professional para WooCommerce para WordPress es vulnerable a la ejecución de códigos cortos arbitrarios en todas las versiones hasta la 1.4.2.2 incluida. Esto se debe a que el software permite a los usuarios ejecutar una acción que no valida correctamente un valor antes de ejecutar do_shortcode. Esto hace posible que atacantes no autenticados ejecuten códigos cortos arbitrarios.

La vulnerabilidad de neutralización incorrecta de la entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en Webcodin WP Visual Adverts permite XSS reflejado. Este problema afecta a WP Visual Adverts: desde n/a hasta 2.3.0.

Vulnerabilidad de neutralización incorrecta de la entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en Narnoo Wordpress developer Narnoo Commerce Manager, permite XSS reflejado. Este problema afecta a Narnoo Commerce Manager: desde n/a hasta 1.6.0.

El complemento The Paid Membership Subscriptions – Effortless Memberships, Recurring Payments & Content Restriction para WordPress es vulnerable a la ejecución de códigos cortos arbitrarios en todas las versiones hasta la 2.13.0 incluida. Esto se debe a que el software permite a los usuarios ejecutar una acción que no valida correctamente un valor antes de ejecutar do_shortcode. Esto hace posible que atacantes no autenticados ejecuten códigos cortos arbitrarios.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: comprobar la validez de nr_words en bpf_iter_bits_new() Compruebe la validez de nr_words en bpf_iter_bits_new(). Sin esta comprobación, cuando se produce un desbordamiento de multiplicación para nr_bits (p. ej., cuando nr_words = 0x0400-0001, nr_bits se convierte en 64), puede producirse una corrupción de la pila debido a bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Solucione el problema limitando el valor máximo de nr_words a 511. El valor se deriva de la implementación actual del asignador de memoria BPF. Para garantizar la compatibilidad si la limitación de tamaño del asignador de memoria BPF cambia en el futuro, utilice el asistente bpf_mem_alloc_check_size() para verificar si nr_bytes es demasiado grande. Y devuelva -E2BIG en lugar de -ENOMEM para nr_bytes de gran tamaño.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Libera bits asignados dinámicamente en bpf_iter_bits_destroy() bpf_iter_bits_destroy() usa "kit->nr_bits <= 64" para comprobar si los bits están asignados dinámicamente. Sin embargo, la comprobación es incorrecta y puede causar una fuga de kmem como se muestra a continuación: objeto sin referencia 0xffff88812628c8c0 (tamaño 32): comm "swapper/0", pid 1, jiffies 4294727320 volcado hexadecimal (primeros 32 bytes): b0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 f0 ..U........... f0 f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): [<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 [<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 [<00000000597124d6>] __alloc.isra.0+0x89/0xb0 [<000000004ebfffcd>] alloc_bulk+0x2af/0x720 [<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 [<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 [<000000008b616eac>] bpf_global_ma_init+0x19/0x30 [<00000000fc473efc>] Esto se debe a que nr_bits se establecerá como cero en bpf_iter_bits_next() después de que se hayan iterado todos los bits. Solucione el problema configurando kit->bit en kit->nr_bits en lugar de configurar kit->nr_bits en cero cuando la iteración se complete en bpf_iter_bits_next(). Además, use "!nr_bits || bits >= nr_bits" para verificar si la iteración está completa y siga usando "nr_bits > 64" para indicar si los bits se asignan dinámicamente. La verificación "!nr_bits" es necesaria porque bpf_iter_bits_new() puede fallar antes de configurar kit->nr_bits, y esta condición detendrá la iteración antes de tiempo en lugar de acceder a los kit->bits liberados o puestos a cero. Teniendo en cuenta que el valor inicial de kit->bits es -1 y el tipo de kit->nr_bits es unsigned int, cambie el tipo de kit->nr_bits a int. El posible problema de desbordamiento se manejará en el siguiente parche.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sock_map: corrige una desreferencia de puntero NULL en sock_map_link_update_prog() La siguiente condición de ejecución podría desencadenar una desreferencia de puntero NULL: sock_map_link_detach(): sock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); mutex_lock(&sockmap_mutex); ... sock_map_prog_link_lookup(sockmap_link->map); mutex_unlock(&sockmap_mutex); Solucione el problema añadiendo una comprobación de puntero NULL. En este caso específico, no tiene sentido actualizar un enlace que se está publicando.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: se corrige el fallo al configurar un gso_max_size/gso_ipv4_max_size pequeño. Configurar un gso_max_size/gso_ipv4_max_size pequeño provocará un desbordamiento en sk_dst_gso_max_size(), lo que puede desencadenar un fallo BUG_ON, porque sk->sk_gso_max_size sería mucho mayor que los límites del dispositivo. Seguimiento de llamadas: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Agregar verificación para el valor mínimo de gso_max_size y gso_ipv4_max_size.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci: corregir null-ptr-deref en hci_read_supported_codecs Corregir __hci_cmd_sync_sk() para que no devuelva NULL para códigos de operación desconocidos. __hci_cmd_sync_sk() devuelve NULL si un comando devuelve un evento de estado. Sin embargo, también devuelve NULL cuando no existe un código de operación en la tabla hci_cc porque hci_cmd_complete_evt() asume status = skb->data[0] para códigos de operación desconocidos. Esto lleva a null-ptr-deref en cmd_sync para HCI_OP_READ_LOCAL_CODECS ya que no hay hci_cc para HCI_OP_READ_LOCAL_CODECS, que siempre asume status = skb->data[0]. KASAN: null-ptr-deref en el rango [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 No contaminado 6.9.0-ga6bcb805883c-dirty #10 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Cola de trabajo: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Código: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Seguimiento de llamadas: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [en línea] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [en línea] hci_init4_sync net/bluetooth/hci_sync.c:4706 [en línea] hci_init_sync net/bluetooth/hci_sync.c:4742 [en línea] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [en línea] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [en línea] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 proceso_uno_trabajo kernel/workqueue.c:3267 [en línea] proceso_trabajos_programados+0x8ef/0x14f0 kernel/workqueue.c:3348 subproceso de trabajo+0x91f/0xe50 kernel/workqueue.c:3429 subproceso de trabajo+0x2cb/0x360 kernel/kthread.c:388 ret_de_bifurcación+0x4d/0x80 arch/x86/kernel/process.c:147 ret_de_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_reject_ipv6: soluciona un posible fallo en nf_send_reset6() Recibí un informe de syzbot sin una reproducción [1] que falla en nf_send_reset6() Creo que el problema es que dev->hard_header_len es cero, e intentamos más tarde enviar un encabezado Ethernet. Utilice LL_MAX_HEADER, como otras funciones en net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: texto:ffffffff89b1d008 longitud:74 puesta:14 cabeza:ffff88803123aa00 datos:ffff88803123a9f2 cola:0x3c fin:0x140 desarrollo:syz_tun ERROR del kernel en net/core/skbuff.c:206 ! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 No contaminado 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [en línea] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Código: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 00000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [en línea] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [en línea] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn incluye/linux/netfilter.h:154 [en línea] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook incluye/linux/netfilter.h:269 [en línea] NF_HOOK incluye/linux/netfilter.h:312 [en línea] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [en línea] nf_hook_bridge_pre net/bridge/br_input.c:277 [en línea] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [en línea] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [en línea] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [en línea] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Código: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 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 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 00000000000008e RSI: 0000000020000040 RDI: 0000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: Se corrige el problema use-after-free en la descarga del módulo ip6table_nat get_info() que tiene una advertencia refcnt para UAF. El seguimiento de llamadas es: ADVERTENCIA: CPU: 1 PID: 379 en kernel/module/main.c:853 module_put+0x6f/0x80 Módulos vinculados en: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables No contaminado 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Seguimiento de llamadas: get_info+0x128/0x180 La ejecución simultánea de la descarga del módulo y get_info() activó la advertencia. La causa raíz es la siguiente: cpu0 cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template kfree(t) //eliminado de la lista de plantillas getinfo() t = xt_find_table_lock list_for_each_entry(tmpl, &xt_templates[af]...) if (strcmp(tmpl->name, name)) continue; //tabla no encontrada try_module_get list_for_each_entry(t, &xt_net->tables[af]...) return t; //no obtener refcnt module_put(t->me) //uaf unregister_pernet_subsys //eliminar tabla de la lista xt_net Mientras el módulo xt_table desaparecía y se eliminaba de la lista xt_templates, no pudimos obtener refcnt de xt_table->me. Verifique el módulo en el recorrido de lista xt_net->tables para solucionarlo.