Vulnerabilidades

La vulnerabilidad de neutralización inadecuada de la entrada durante la generación de páginas web ('Cross-site Scripting') en Jordy Meow Media Alt Renamer permite almacenar XSS. Este problema afecta a Media Alt Renamer: desde n/a hasta 0.0.1.

El complemento Marketing Optimizer para WordPress es vulnerable a la Cross-Site Request Forgery en todas las versiones hasta la 20200925 incluida. Esto se debe a una validación nonce faltante o incorrecta a través del archivo admin/main-settings-page.php. Esto hace posible que atacantes no autenticados actualicen la configuración del complemento e inyecten JavaScript malicioso a través de una solicitud falsificada, siempre que puedan engañar al administrador del sitio para que realice una acción como hacer clic en un enlace.

Carga sin restricciones de archivos con vulnerabilidad de tipo peligroso en Mollie Mollie Payments para WooCommerce. Este problema afecta a Mollie Payments para WooCommerce: desde n/a hasta 7.3.11.

La vulnerabilidad de neutralización inadecuada de la entrada durante la generación de páginas web ('Cross-site Scripting') en José Fernandez Adsmonetizer permite Reflected XSS. Este problema afecta a Adsmonetizer: desde n/a hasta 3.1.2.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: errata: Agregar workaround de carga especulativa sin privilegios de Cortex-A520 Implementar la workaround para la errata 2966298 de ARM Cortex-A520. En un núcleo Cortex-A520 afectado, una carga sin privilegios ejecutada especulativamente podría filtrarse datos de una carga privilegiada a través de un canal lateral de caché. El problema sólo existe para cargas dentro de un régimen de traducción con la misma traducción (por ejemplo, el mismo ASID y VMID). Por tanto, el problema sólo afecta al retorno a EL0. La solución es ejecutar un TLBI antes de regresar a EL0 después de todas las cargas de datos privilegiados. Un TLBI que no se pueda compartir con cualquier dirección es suficiente. El workaround no es necesario si el aislamiento de la tabla de páginas (KPTI) está habilitado, pero por simplicidad lo será. El aislamiento de la tabla de páginas normalmente debe estar deshabilitado para Cortex-A520, ya que admite la función CSV3 y la función E0PD (utilizada cuando KASLR está habilitado).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/x86/lbr: Filtrar direcciones vsyscall Descubrimos que puede ocurrir un pánico cuando se realiza una vsyscall mientras el muestreo LBR está activo. Si el VSYSCALL se interrumpe (NMI) para el muestreo de Perf, esta secuencia de llamadas puede ocurrir (más reciente en la parte superior): __insn_get_emulate_prefix () insn_get_emulate_prefix () insn_get_prefixes () insn_get_opcode () decode_branch_type () get_branch_type () _pmu_handle_irq () perf_event_nmi_handler ( ) Dentro de __insn_get_emulate_prefix() en el cuadro 0, se llama una macro: peek_nbyte_next(insn_byte_t, insn, i) Dentro de esta macro, se produce esta desreferencia: (insn)->next_byte Inspeccionando registros en este punto, el valor del campo next_byte es el dirección de vsyscall realizada, por ejemplo, la ubicación de la versión vsyscall de gettimeofday() en 0xffffffffff600000. El acceso a una dirección en la región vsyscall provocará un error debido a un error de página no controlado. Para corregir el error, se puede filtrar por vsyscalls al determinar el tipo de rama. Este parche devolverá una rama "ninguna" si se encuentra que una dirección del kernel se encuentra en la región vsyscall.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: logitech-hidpp: soluciona el fallo del kernel en la desconexión del USB del receptor hidpp_connect_event() tiene *cuatro* carreras de tiempo de verificación versus tiempo de uso (TOCTOU) cuando corre consigo mismo. hidpp_connect_event() se ejecuta principalmente desde una cola de trabajo, pero también se ejecuta en probe() y si el hw recibe un paquete "dispositivo conectado" cuando el subproceso que ejecuta hidpp_connect_event() desde probe() está esperando en el hw, entonces se ejecuta un segundo El hilo que ejecuta hidpp_connect_event() se iniciará desde la cola de trabajo. Esto abre las siguientes carreras (tenga en cuenta que el código siguiente está simplificado):1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: hub: protege contra accesos a descriptores BOS no inicializados Muchas funciones en drivers/usb/core/hub.c y drivers/usb/core/hub.h acceden a los campos dentro de udev- >bos sin verificar si fue asignado e inicializado. Si usb_get_bos_descriptor() falla por cualquier motivo, udev->bos será NULL y esos accesos resultarán en un bloqueo: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000018 PGD 0 P4D 0 Vaya: 0000 [#1] CPU PREEMPT SMP NOPTI : 5 PID: 17818 Comm: kworker/5:1 Tainted: GW 5.15.108-18910-gab0e1cb584e1 #1 Nombre de hardware: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 03/02/2021 Cola de trabajo : usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Código: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 000000 0000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: ffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 00000000 00000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 00000000000000000 FS: 0000000000000000(0000) GS:ffffa1be965 40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Seguimiento de llamadas: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f proceso_one_work+0x1a2/0x487 trabajador_thread+0x11a/0x288 kthread+0x13a/0x152 ? proceso_one_work+0x487/0x487? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Vuelva a un comportamiento predeterminado si no se puede acceder al descriptor BOS y omita todas las funcionalidades que dependen de él: comprobaciones de compatibilidad con LPM, comprobaciones de capacidad de supervelocidad, configuración de estados U1/U2.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Entrada: powermate - corrige el use-after-free en powermate_config_complete syzbot ha encontrado un error de use-after-free [1] en el controlador powermate. Esto sucede cuando el dispositivo está desconectado, lo que genera una memoria libre de la estructura powermate_device. Cuando se completa un mensaje de control asincrónico después de que se invoca kfree y su devolución de llamada, el bloqueo ya no existe y de ahí el error. Utilice usb_kill_urb() en pm->config para cancelar cualquier solicitud en curso al desconectar el dispositivo. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e

Vulnerabilidad de autorización faltante en Perfmatters. Este problema afecta a Perfmatters: desde n/a hasta 2.1.6.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrige uaf en smb20_oplock_break_ack elimina la referencia después de usar opinfo.

La vulnerabilidad de neutralización inadecuada de la entrada durante la generación de páginas web ('Cross-site Scripting') en Melapress WP Activity Log permite almacenar XSS. Este problema afecta el WP Activity Log: desde n/a hasta 4.6.1.