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 TOTOLINK X5000R y TOTOLINK A7000R (CVE-2023-36947)
Severidad: Pendiente de análisis
Fecha de publicación: 16/10/2023
Fecha de última actualización: 12/09/2024
Se descubrió que TOTOLINK X5000R V9.1.0u.6118_B20201102 y TOTOLINK A7000R V9.1.0u.6115_B20201022 contenían un desbordamiento de pila a través del parámetro File en la función UploadCustomModule.
Vulnerabilidad en SAP BusinessObjects Business Intelligence (CVE-2024-41730)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
En la plataforma SAP BusinessObjects Business Intelligence, si el inicio de sesión único está habilitado en la autenticación empresarial, un usuario no autorizado puede obtener un token de inicio de sesión mediante un endpoint REST. El atacante puede comprometer completamente el sistema, lo que tendrá un alto impacto en la confidencialidad, la integridad y la disponibilidad.
Vulnerabilidad en SAP Commerce (CVE-2024-41733)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
En SAP Commerce, las cuentas de usuario válidas se pueden identificar durante los procesos de registro e inicio de sesión del cliente. Esto permite a un atacante potencial saber si un correo electrónico determinado se utiliza para una cuenta, pero no otorga acceso a ningún dato del cliente más allá de este conocimiento. El atacante ya debe conocer el correo electrónico que desea probar. Por lo tanto, el impacto sobre la confidencialidad es bajo y no afecta la integridad o la disponibilidad.
Vulnerabilidad en SAP Commerce Backoffice (CVE-2024-41735)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
SAP Commerce Backoffice no codifica suficientemente las entradas controladas por el usuario, lo que genera una vulnerabilidad de Cross-Site Scripting (XSS) que causa un bajo impacto en la confidencialidad y la integridad de la aplicación.
Vulnerabilidad en SAP Permit to Work (CVE-2024-41736)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
Bajo ciertas condiciones, SAP Permit to Work permite que un atacante autenticado acceda a información que de otro modo estaría restringida, lo que causa un bajo impacto en la confidencialidad de la aplicación.
Vulnerabilidad en SAP CRM ABAP (CVE-2024-41737)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
SAP CRM ABAP (Insights Management) permite a un atacante autenticado enumerar endpoints HTTP en la red interna mediante la elaboración especial de solicitudes HTTP. Si se explota con éxito, esto puede dar lugar a la divulgación de información. No tiene ningún impacto en la integridad y disponibilidad de la aplicación.
Vulnerabilidad en SAP BusinessObjects Business Intelligence (CVE-2024-42375)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
La plataforma SAP BusinessObjects Business Intelligence permite a un atacante autenticado cargar código malicioso a través de la red, que podría ser ejecutado por la aplicación. Si la explotación tiene éxito, el atacante puede causar un impacto bajo en la integridad de la aplicación.
Vulnerabilidad en SAP Shared Service Framework (CVE-2024-42376)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
SAP Shared Service Framework no realiza la verificación de autorización necesaria para un usuario autenticado, lo que resulta en una escalada de privilegios. Si la explotación tiene éxito, un atacante puede causar un gran impacto en la confidencialidad de la aplicación.
Vulnerabilidad en SAP (CVE-2024-42377)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
El framework de servicios compartidos de SAP permite a un usuario no administrativo autenticado llamar a una función habilitada de forma remota, lo que le permitirá insertar entradas de valores en una tabla no confidencial, lo que causa un bajo impacto en la integridad de la aplicación.
Vulnerabilidad en SAP Document Builder (CVE-2024-39591)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
SAP Document Builder no realiza las comprobaciones de autorización necesarias para uno de los módulos de funciones, lo que da como resultado una escalada de privilegios que tiene un bajo impacto en la confidencialidad de la aplicación.
Vulnerabilidad en SAP NetWeaver Application Server ABAP y ABAP Platform (CVE-2024-41734)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
Debido a la falta de verificación de autorización en SAP NetWeaver Application Server ABAP y ABAP Platform, un atacante autenticado podría llamar a una transacción subyacente, lo que conduce a la divulgación de información relacionada con el usuario. No hay ningún impacto en la integridad o la disponibilidad.
Vulnerabilidad en SAP Student Life Cycle Management (SLcM) (CVE-2024-42373)
Severidad: Pendiente de análisis
Fecha de publicación: 13/08/2024
Fecha de última actualización: 12/09/2024
SAP Student Life Cycle Management (SLcM) no realiza comprobaciones de autorización adecuadas para los usuarios autenticados, lo que genera una posible escalada de privilegios. Si se explota con éxito, podría permitir a un atacante eliminar variantes de informes no confidenciales que normalmente están restringidas, causando un impacto mínimo en la integridad de la aplicación.
Vulnerabilidad en kernel de Linux (CVE-2023-52914)
Severidad: Pendiente de análisis
Fecha de publicación: 21/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring/poll: agregue hash si la solicitud de sondeo lista no se puede completar en línea. Si no lo hacemos, podemos perder el acceso a ella por completo, lo que provocará una fuga de solicitud. Esto eventualmente también detendrá el proceso de salida del anillo.
Vulnerabilidad en kernel de Linux (CVE-2022-48901)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no inicie la reubicación hasta que se completen las caídas en progreso. Nos topamos con un error con una reubicación de recuperación en el montaje para uno de nuestros sistemas de archivos en producción. Reproduje esto localmente inyectando errores en la eliminación de instantáneas con el saldo ejecutándose al mismo tiempo. Esto se presentó como un error al buscar un elemento de extensión ADVERTENCIA: CPU: 5 PID: 1501 en fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance No contaminado 5.16 .0-rc8+ #8 RIP: 0010:lookup_inline_extent_backref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 3: 000000010f092000 CR4: 0000000000350ee0 Seguimiento de llamadas: insert_inline_extent_backref+0x46/0xd0 __btrfs_inc_extent_ref.isra.0+0x5f/0x200 ? btrfs_merge_delayed_refs+0x164/0x190 __btrfs_run_delayed_refs+0x561/0xfa0 ? btrfs_search_slot+0x7b4/0xb30? btrfs_update_root+0x1a9/0x2c0 btrfs_run_delayed_refs+0x73/0x1f0 ? btrfs_update_root+0x1a9/0x2c0 btrfs_commit_transaction+0x50/0xa50 ? btrfs_update_reloc_root+0x122/0x220 prepare_to_merge+0x29f/0x320 relocate_block_group+0x2b8/0x550 btrfs_relocate_block_group+0x1a6/0x350 btrfs_relocate_chunk+0x27/0xe0 btrfs_balance+0x777/0xe60 balance_kthread+0x35/0x50? btrfs_balance+0xe60/0xe60 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Normalmente, fs_info->cleaner_mutex excluye la ejecución simultánea de la eliminación y reubicación de instantáneas. Sin embargo, si tuviéramos un saldo pendiente esperando obtener ->cleaner_mutex, y se estuviera ejecutando una eliminación de instantánea y luego el cuadro fallara, llegaríamos a un estado en el que tendríamos una instantánea medio eliminada. Nuevamente, en el caso normal, la eliminación de la instantánea debe completarse antes de que pueda comenzar la reubicación, pero en este caso la reubicación podría muy bien comenzar antes de que se complete la eliminación de la instantánea, ya que simplemente agregamos la raíz a la lista de raíces muertas y esperamos la próxima vez que se complete la eliminación de la instantánea. El limpiador se ejecuta para limpiar la instantánea. Solucione este problema configurando un bit en fs_info si tenemos algún DEAD_ROOT que tenga una clave drop_progress pendiente. Si lo hacen, entonces sabremos que estábamos en medio de la operación de colocación y configuramos una bandera en fs_info. Luego, el saldo puede esperar hasta que se borre esta bandera para comenzar nuevamente. Si hay DEAD_ROOT que no tienen drop_progress configurado, entonces podemos comenzar a equilibrar de inmediato, ya que estaremos protegidos adecuadamente por clean_mutex.
Vulnerabilidad en kernel de Linux (CVE-2022-48902)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no haga WARN_ON() si tenemos configurado PageError. Siempre que realizamos operaciones de búfer de extensión, llamamos a afirmar_eb_page_uptodate() para quejarnos en voz alta si estamos operando en una página no actualizada. Nuestras pruebas nocturnas detectaron esta advertencia a principios de esta semana ADVERTENCIA: CPU: 1 PID: 553508 en fs/btrfs/extent_io.c:6849 afirmar_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: GW 5.17. 0-rc3+ #564 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 01/04/2014 Cola de trabajo: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018 :ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 00000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Seguimiento de llamadas: extend_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree +0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60? rcu_read_lock_sched_held+0x12/0x60? rcu_read_lock_sched_held+0x12/0x60? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0? terminar_task_switch.isra.0+0xf9/0x3a0 proceso_one_work+0x26d/0x580 ? proceso_one_work+0x580/0x580 trabajador_thread+0x55/0x3b0? proceso_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Esto fue solucionado parcialmente por c2e39305299f01 ("btrfs: borrar la actualización del búfer de extensión cuando no logramos escribirlo"), sin embargo, todo lo que esa solución hizo fue evitar que encontráramos búferes de extensión después de una escritura fallida. Eso no nos impidió seguir usando un búfer que ya habíamos encontrado. En este caso, estamos buscando la raíz de confirmación para almacenar en caché el grupo de bloques, de modo que podamos comenzar a confirmar la transacción, cambiar la raíz de confirmación y luego comenzar a escribir. Después del cambio, podemos buscar un búfer de extensión que aún no se ha escrito y comenzar a procesar ese grupo de bloques. Luego no escribimos ese bloqueo y borramos Actualizar en la página, y luego comenzamos a arrojar estos errores. Normalmente aquí estamos protegidos hasta cierto punto por el candado del árbol. Si leemos un bloque, tenemos la lectura del bloque bloqueada y evitamos que el escritor bloquee el bloque antes de enviarlo para la escritura. Sin embargo, esto no es necesariamente infalible porque la lectura podría ocurrir antes de submit_bio y después de bloquear y desbloquear el búfer de extensión. También en este caso particular tenemos configurado path->skip_locking, por lo que eso no nos salvará aquí. Simplemente obtendremos un bloque que era válido cuando lo leímos, pero dejó de ser válido mientras lo usábamos. Lo que realmente queremos es detectar el caso en el que hemos "leído" un bloque pero no está marcado como Actualizado. Al leer, usamos ClearPageError(), por lo que si estamos !Uptodate y !Error sabremos que no hicimos lo correcto al leer la página. Solucione esto marcando !Uptodate && !Error, de esta manera no nos quejaremos si nuestro búfer se invalida mientras lo estamos usando, y mantendremos el espíritu de la verificación, que es asegurarnos de que tengamos un caché completo. bloquear mientras estamos jugando con él.
Vulnerabilidad en kernel de Linux (CVE-2022-48903)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige el fallo de reubicación debido al retorno prematuro de btrfs_commit_transaction() Estamos viendo fallos similares al siguiente rastro: [38.969182] ADVERTENCIA: CPU: 20 PID: 2105 en fs/btrfs /relocation.c:4070 btrfs_relocate_block_group + 0x2dc/0x340 [btrfs] [38.973556] cpu: 20 pid: 2105 coms: btrfs no tinted 5.17.0-rc4 #54 [38.974580] nombre de hardware: qtrfs no tinteded 5.17.0-rc4 #54 [38.974580] Nombre de hardware: QTRFS no está Tainted 5.17.0-rc4 #54 [38.974580] Nombre de hardware: QTRFS no Tainted 5.17.0-rc4 #54 [38.974580] Nombre de hardware: QTRFS no Tainted 5.17.0-rc4 #54 [38.974580] Nombre de hardware: QTRFS no Tainted 5.17. ), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 01/04/2014 [38.976539] RIP: 0010:btrfs_relocate_block_group+0x2dc/0x340 [btrfs] [38.980336] RSP: 42e03c20 EFLAGS: 00010206 [ 38.981218] RAX: ffff96cfc4ede800 RBX: ffff96cfc3ce0000 RCX: 000000000002ca14 [38.982560] RDX: 00000000000000000 RSI: 4cfd109a0bcb5d7f RDI: 3ce0360 [38.983619] RBP: ffff96cfc309c000 R08: 0000000000000000 R09: 0000000000000000 [38.984678] R10: ffff96cec0000001 R11: 12: ffff96cfc4ede800 [38.985735] R13: 0000000000000000 R14: 0000000000000000 R15: ffff96cfc3ce0360 [38.987146] FS: 00007f11c15218c0(0000) GS:ffff96d6dfb00000(0000) 0000000000000000 [38.988662] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [38.989398] CR2: 00007ffc922c8e60 CR3: 00000001147a6001 CR4: 0000000000370ee0 [38.990279] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 00000000000000000 [38.991219] DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [38.992528] Seguimiento de llamadas: [38.992854] [38.993148] btrfs_relocate_chunk+0x27/0xe0 [btrfs ] [38.993941] btrfs_balance+0x78e/0xea0 [btrfs] [38.994801] ? vsnprintf+0x33c/0x520 [38.995368] ? __kmalloc_track_caller+0x351/0x440 [38.996198] btrfs_ioctl_balance+0x2b9/0x3a0 [btrfs] [38.997084] btrfs_ioctl+0x11b0/0x2da0 [btrfs] [38.997867] ? mod_objcg_state+0xee/0x340 [38.998552] ? seq_release+0x24/0x30 [38.999184] ? proc_nr_files+0x30/0x30 [38.999654] ? call_rcu+0xc8/0x2f0 [39.000228] ? __x64_sys_ioctl+0x84/0xc0 [39.000872] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs] [39.001973] __x64_sys_ioctl+0x84/0xc0 [39.002566] do_syscall_64+0x3a/0x80 [39.003011] Entry_SYSCALL_64_after_hwframe+ 0x44/0xae [39.003735] RIP: 0033:0x7f11c166959b [39.007324] RSP: 002b:00007fff2543e998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [39.008521] RAX: ffffffffffffffda RBX: 00007f11c1521698 RCX: 00007f11c166959b [39.009833] RDX: 00007fff2543 ea40 RSI: 00000000c4009420 RDI: 00000000000000003 [39.011270] RBP: 0000000000000003 R08: 00000000000000013 R09: 00007f11c16f94e0 [39.0125 81] R10: 0000000000000000 R11: 0000000000000246 R12 : 00007fff25440df3 [39.014046] R13: 00000000000000000 R14: 00007fff2543ea40 R15: 0000000000000001 [39.015040] [39.015418] ---[ final de seguimiento 0 000000000000000 ]--- [43.131559] ------------ [cortar aquí]------------ [43.132234] ¡ERROR del kernel en fs/btrfs/extent-tree.c:2717! [43.133031] código de operación no válido: 0000 [#1] PREEMPT SMP PTI [43.133702] CPU: 1 PID: 1839 Comm: btrfs Tainted: GW 5.17.0-rc4 #54 [43.134863] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 01/04/2014 [43.136426] RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs] [43.139913] RSP: 216bc70 EFLAGS: 00010246 [43.140629] RAX: 0000000000000000 RBX: ffff96cfc34490f8 RCX: 0000000000000001 [43.141604] RDX: 0000000080000001 RSI: 0000000051d00000 : 00000000ffffffff [43.142645] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff96cfd07dca50 [43.143669] R10: ffff96cfc46e8a00 R11: 00 R12: 0000000041d00000 [43.144657 ] R13: ffff96cfc3ce0000 R14: ffffb0dd4216bd08 R15: 0000000000000000 [43.145686] FS: 00007f7657dd68c0(0000) GS:ffff96d6df640000(0000) 00000000000000 [43.146808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43.147584] CR2: 00007f7fe81bf5b0 CR3 : 00000001093ee004 CR4: 0000000000370ee0 [43.148589] ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-48904)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/amd: corrige la pérdida de memoria de la tabla de páginas de E/S. La lógica actual actualiza el modo de tabla de páginas de E/S para el dominio antes de llamar a la lógica para liberar la memoria utilizada para la tabla de páginas. Esto da como resultado una pérdida de memoria en la tabla de páginas de IOMMU y se puede observar al iniciar VM con dispositivos de paso. Se soluciona liberando la memoria utilizada para la tabla de páginas antes de actualizar el modo.
Vulnerabilidad en kernel de Linux (CVE-2022-48905)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: elemento de trabajo de reinicio gratuito al vaciar Se corrige una pequeña pérdida de memoria al vaciar la cola de trabajo de reinicio.
Vulnerabilidad en kernel de Linux (CVE-2022-48906)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: establece correctamente el tiempo de espera de DATA_FIN cuando el número de retransmisiones es grande Syzkaller con UBSAN descubrió un escenario en el que una gran cantidad de retransmisiones de DATA_FIN provocaban un desplazamiento fuera de los límites en el tiempo de espera de DATA_FIN cálculo: =================================================== ================================ UBSAN: desplazamiento fuera de los límites en net/mptcp/protocol.c: El exponente de desplazamiento 470:29 32 es demasiado grande para el tipo 'unsigned int' de 32 bits CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Cola de trabajo: eventos mptcp_worker Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack .c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330 mptcp_set_datafin_timeout net/mptcp/protocol.c:470 __mptcp_retrans.cold+0x7 2/0x77 net/mptcp/protocol.c:2445 mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528 Process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307 trabajador_thread+0x95/0xe10 kernel/workqueue.c:2454 kthread+0x2f4 /0x3b0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ====================== ==================================================== ========= Este cambio limita el tiempo de espera máximo al limitar el tamaño del turno, lo que mantiene todos los valores intermedios dentro de los límites.
Vulnerabilidad en kernel de Linux (CVE-2022-48907)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: auxdisplay: lcd2s: corrige la pérdida de memoria en ->remove() Una vez asignada, la estructura lcd2s_data nunca se libera. Solucione la pérdida de memoria cambiando a devm_kzalloc().
Vulnerabilidad en kernel de Linux (CVE-2022-48908)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: arcnet: com20020: corrija null-ptr-deref en com20020pci_probe() Durante la inicialización del controlador, se requiere el puntero de información de la tarjeta, es decir, la variable 'ci'. Sin embargo, la definición de 'com20020pci_id_table' revela que este campo está vacío para algunos dispositivos, lo que provocará una desreferencia del puntero nulo al inicializar estos dispositivos. El siguiente registro lo revela: [3.973806] KASAN: null-ptr-deref en el rango [0x0000000000000028-0x000000000000002f] [3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_p ci] [3.975181] Seguimiento de llamadas: [3.976208] local_pci_probe+0x13f /0x210 [3.977248] pci_device_probe+0x34c/0x6d0 [3.977255]? pci_uevent+0x470/0x470 [3.978265] very_probe+0x24c/0x8d0 [3.978273] __driver_probe_device+0x1b3/0x280 [3.979288] driver_probe_device+0x50/0x370 Solucione este problema comprobando primero si el 'ci' es un puntero nulo.
Vulnerabilidad en kernel de Linux (CVE-2022-48909)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: reparar fuga de conexión Hay un posible problema de fuga en la siguiente secuencia de ejecución: smc_release smc_connect_work if (sk->sk_state == SMC_INIT) send_clc_confirim tcp_abort(); ... sk.sk_state = SMC_ACTIVE smc_close_active switch(sk->sk_state) { ... case SMC_ACTIVE: smc_close_final() // luego espera el par cerrado Desafortunadamente, tcp_abort() puede descartar los mensajes CLC CONFIRM que todavía están en el búfer de envío tcp , en cuyo caso nuestro token de conexión no se puede entregar al lado del servidor, lo que significa que no podemos recibir ningún mensaje de cierre pasivo. Por lo tanto, es imposible desconectarlo en absoluto. Este parche intenta una forma muy sencilla de evitar este problema, una vez que el estado ha cambiado a SMC_ACTIVE después de tcp_abort(), podemos cancelar activamente la conexión smc, considerando que el estado es SMC_INIT antes de tcp_abort(), abandonar el proceso de desconexión completo no debería causar demasiado problema. De hecho, este problema puede existir siempre y cuando el servidor no reciba el mensaje CONFIRM CLC. En el futuro se deberá discutir si se debe agregar un temporizador después de smc_close_final(). Pero aun así, este parche proporciona una liberación más rápida para la conexión. En el caso anterior, también debería ser valioso.
Vulnerabilidad en kernel de Linux (CVE-2022-48910)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv6: asegúrese de llamar a ipv6_mc_down() como máximo una vez. Hay dos razones para llamar a addrconf_notify() con NETDEV_DOWN: o el dispositivo de red realmente está cayendo o IPv6 estaba deshabilitado en la interfaz. Si alguno de ellos permanece inactivo mientras el otro está activado, llamamos repetidamente al código para NETDEV_DOWN, incluido ipv6_mc_down(), pero nunca llamamos al ipv6_mc_up() correspondiente en el medio. Esto hará que se asigne una nueva entrada en idev->mc_tomb para cada grupo de multidifusión al que esté suscrita la interfaz, lo que a su vez filtrará una estructura ifmcaddr6 por cada grupo de multidifusión no trivial al que esté suscrita la interfaz. El siguiente reproductor filtrará al menos $n objetos: ip addr add ff2e::4242/32 dev eth0 autojoin sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 for i in $(seq 1 $n); configurar el enlace ip eth0; ip link set down eth0 done Unirse a grupos con IPV6_ADD_MEMBERSHIP (sin privilegios) o configurar sysctl net.ipv6.conf.eth0.forwarding en 1 (=> suscribirse a ff02::2) también se puede usar para crear un idev->mc_list no trivial , que filtrará objetos con la secuencia correcta de arriba a abajo. Según ambas fuentes de eventos NETDEV_DOWN, se debe considerar el estado de la interfaz IPv6: - no lista si la interfaz de red no está lista O IPv6 está deshabilitado - lista si la interfaz de red está lista Y IPv6 está habilitada Las funciones ipv6_mc_up() e ipv6_down() solo debe ejecutarse cuando este estado cambie. Implemente esto recordando cuándo el estado de IPv6 está listo y solo ejecute ipv6_mc_down() si realmente cambió de listo a no listo. La otra dirección (no listo -> listo) ya funciona correctamente, ya que: - la ruta de código activada de notificación de interfaz para NETDEV_UP / NETDEV_CHANGE regresa antes si ipv6 está deshabilitado, y - la ruta de código activada enable_ipv6=0 omite la inicialización completa de la interfaz siempre que addrconf_link_ready (dev) devuelve falso: llamar a ipv6_mc_up() repetidamente no filtra nada
Vulnerabilidad en kernel de Linux (CVE-2022-48911)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_queue: corrige posible use-after-free Eric Dumazet dice: El lado sock_hold() parece sospechoso, porque no hay garantía de que sk_refcnt no sea ya 0. En caso de falla, No podemos poner en cola el paquete y necesitamos indicar un error. La persona que llama descartará el paquete. v2: dividir el fragmento de captación previa de skb en un cambio separado
Vulnerabilidad en kernel de Linux (CVE-2022-48914)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/netfront: destruye colas antes de que real_num_tx_queues se ponga a cero xennet_destroy_queues() se basa en info->netdev->real_num_tx_queues para eliminar colas. Dado que d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: actualice los recuentos de colas en la ruta de cancelación de registro"), unregister_netdev() establece indirectamente real_num_tx_queues en 0. Esos dos hechos juntos significan que xennet_destroy_queues() llamado desde xennet_remove() no puede hacer su trabajo, porque s llamado después de unregister_netdev(). Esto da como resultado colas kfree-ing que todavía están vinculadas en napi, lo que finalmente falla: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - PGD de página no presente 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 52 Comm: xenwatch Tainted: GW 5.16.10-1.32.fc32.qubes.x86_64+ #226 RIP: 0010:free_netdev+0xa3/0x1a0 Código: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 0 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00 RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000 RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff RBP: fffffffffffffea0 R08: 00000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 R13: ffff8880065f8f88 R14: 00000000000000000 R15: ffff8880066c6680 FS: 00000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: CR3: 00000000e998c006 CR4: 00000000003706e0 Seguimiento de llamadas: xennet_remove+0x13d/0x300 [xen_netfront] xenbus_dev_remove+0x6d/0xf0 __device_release_driver+0x17a/0x240 device_release_driver+0x24/ 0x30 bus_remove_device+0xd8/0x140 dispositivo_del+0x18b/0x410? _raw_spin_unlock+0x16/0x30? klist_iter_exit+0x14/0x20? xenbus_dev_request_and_reply+0x80/0x80 dispositivo_unregister+0x13/0x60 xenbus_dev_changed+0x18e/0x1f0 xenwatch_thread+0xc0/0x1a0 ? do_wait_intr_irq+0xa0/0xa0 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Solucione este problema llamando a xennet_destroy_queues() desde xennet_uninit(), cuando real_num_tx_queues todavía esté disponible. Esto garantiza que las colas se destruyan cuando real_num_tx_queues se establece en 0, independientemente de cómo se llamó a unregister_netdev(). Reportado originalmente en https://github.com/QubesOS/qubes-issues/issues/7257
Vulnerabilidad en kernel de Linux (CVE-2022-48916)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: se corrige el doble list_add al habilitar VMD en modo escalable Al habilitar VMD e IOMMU en modo escalable, se muestra el siguiente registro de kernel/rastreo de llamadas de pánico del kernel en la plataforma Eagle Stream (CPU Sapphire Rapids) durante el arranque: pci 0000:59:00.5: Agregar al grupo iommu 42... vmd 0000:59:00.5: Puente de host PCI al bus 10000:80 pci 10000:80:01.0: [8086:352a] tipo 01 clase 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: habilitación de etiquetas extendidas pci 10000:80:01.0: PME# compatible desde D0 D3hot D3cold pci 10 000:80: 01.0: DMAR: La configuración de RID2PASID falló pci 10000:80:01.0: No se pudo agregar al grupo iommu 42: -16 pci 10000:80:03.0: [8086:352b] tipo 01 clase 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64 bits] pci 10000:80:03.0: habilitación de etiquetas extendidas pci 10000:80:03.0: PME# admitido desde D0 D3hot D3cold ------------[ cortar aquí ]--- --------- ¡ERROR del kernel en lib/list_debug.c:29! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Nombre del hardware: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/ Cola de trabajo 2022: eventos work_for_cpu_fn RIP: 0010:__list_add_valid.cold+0x26/0x3f Código: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 00000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: 888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS :0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Llamar Seguimiento: intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0 x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x 820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 proceso_one_work +0x1e2/0x3b0 hilo_trabajador+0x1c4/0x3a0 ? hilo_rescate+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 módulos vinculados en: --- [end rastre 0xffffffff80000000-0xffffffffbffffff) ---[ fin del pánico del kernel - no se sincroniza: excepción grave ]--- La siguiente salida 'lspci' muestra que los dispositivos '10000:80:*' son subdispositivos del dispositivo VMD 0000:59:00.5: $ lspci ... 0000:59:00.5 Controlador de bus RAID: Dispositivo de administración de volumen Intel Corporation Controlador RAID NVMe (rev. 20) ... 10000:80:01.0 Puente PCI: Dispositivo Intel Corporation 352a (rev. 03) 10000:80:03.0 Puente PCI : Dispositivo Intel Corporation 352b (rev 03) 10000:80:05.0 Puente PCI: Dispositivo Intel Corporation 352c (rev 03) 10000:80:07.0 Puente PCI: Dispositivo Intel Corporation 352d (rev 03) 10000:81:00.0 Memoria no volátil controlador: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-48917)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ops: Shift valores probados en snd_soc_put_volsw() por +min Mientras que los valores $val/$val2 pasados desde el espacio de usuario son siempre >= 0 enteros, los límites del control pueden ser números enteros con signo y $min puede ser distinto de cero y menor que cero. Para validar correctamente $val/$val2 contra platform_max, primero agregue el desplazamiento $min a val.
Vulnerabilidad en kernel de Linux (CVE-2022-48920)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: elimina la advertencia en el commit de transacción cuando se usa fluoncommit Cuando se usa la opción de montaje fluoncommit, durante casi cada commit de transacción activamos una advertencia de __writeback_inodes_sb_nr(): $ cat fs/fs -writeback.c: (...) vacío estático __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (... ) La traza producida en dmesg se parece a la siguiente: [947.473890] ADVERTENCIA: CPU: 5 PID: 930 en fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Módulos vinculados en: nfsd nls_cp437 cifs asn1_decoder s_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti No contaminado 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: __writeback_inodes_sb_nr +0x7e/0xb3 [947.502097] Código: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 X: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP : ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 00000000000000002 R11: 0000000000000001 R12: ffff88810096 3488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40 000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e 0 [947.571072] Seguimiento de llamadas: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? Schedule_timeout+0x8a/0xdd [947.582716] transacción_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]--- Esto se debe a que comenzamos a usar writeback_inodes_sb() para vaciar delalloc cuando cometer una transacción (cuando se usa -o fluoncommit), para evitar interbloqueos con las operaciones de congelación del sistema de archivos. Este cambio se realizó mediante el commit ce8ea7cc6eb313 ("btrfs: no llame a btrfs_start_delalloc_roots en flowoncommit"). Después de ese cambio, comenzamos a producir esa advertencia y, de vez en cuando, un usuario informa esto ya que la advertencia ocurre con demasiada frecuencia, envía spam a dmesg/syslog y el usuario no está seguro de si esto refleja algún problema que pueda comprometer la confiabilidad del sistema de archivos. No podemos simplemente bloquear el semáforo sb->s_umount antes de llamar a writeback_inodes_sb(), porque eso al menos bloquearía el sistema de archivos, ya que en fs/super.c:freeze_super() se llama a sync_filesystem() mientras mantenemos ese semáforo en modo de escritura, y eso puede desencadenar un commit de transacción, lo que resulta en un punto muerto. También desencadenaría el mismo tipo de punto muerto en la ruta de desmontaje. Posiblemente, también podría introducir algunas otras dependencias de bloqueo que lockdep informaría. Para solucionar este problema, llame a try_to_writeback_inodes_sb() en lugar de writeback_inodes_sb(), porque intentará leer el bloqueo sb->s_umount y luego solo llamará a writeback_inodes_sb() si pudo bloquearlo. Esto está bien porque los casos en los que no puede leer el bloqueo sb->s_umount son durante un desmontaje del sistema de archivos o durante una congelación del sistema de archivos; en esos casos, sb->s_umount está bloqueado contra escritura y se llama a sync_filesystem(), que llama a writeback_inodes_sb() . En otras palabras, en todos los casos en los que no podemos adoptar un bloqueo de lectura en sb->s_umount, la reescritura ya se está activando en otro lugar. ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-48921)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/fair: Solucionar falla en reweight_entity Syzbot encontró un GPF en reweight_entity. Esto se ha dividido en dos para el commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() accede a un sched_task_group no válido") Hay una ejecución entre sched_post_fork() y setpriority(PRIO_PGRP) dentro de un grupo de subprocesos que provoca un null-ptr-deref en reweight_entity () en el SFC. El escenario es que el proceso principal genera una cantidad de subprocesos nuevos, que luego llaman a setpriority(PRIO_PGRP, 0, -20), esperan y salen. Para cada uno de los nuevos subprocesos, se invoca copy_process(), lo que agrega la nueva task_struct y llama a sched_post_fork() para ello. En el escenario anterior existe la posibilidad de que se llame a setpriority(PRIO_PGRP) y set_one_prio() para un subproceso en el grupo que acaba de crear copy_process(), y para el cual sched_post_fork() aún no se ha ejecutado. Esto desencadenará una desreferencia del puntero nulo en reweight_entity(), ya que intentará acceder al puntero de la cola de ejecución, que no se ha configurado. Antes del cambio mencionado, el puntero cfs_rq para la tarea se configuró en sched_fork(), que se llama mucho antes en copy_process(), antes de que la nueva tarea se agregue al thread_group. Ahora se hace en sched_post_fork(), que se llama después de eso. Para solucionar el problema, elimine el parámetro update_load de la función update_load param() y llame a reweight_task() solo si el indicador de tarea no tiene establecido el indicador TASK_NEW.
Vulnerabilidad en kernel de Linux (CVE-2022-48922)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrige los errores causados por el rastreador de latencia irqsoff trace_hardirqs_{on,off}() requiere que la persona que llama configure el puntero del marco correctamente. Esto se debe a que estas dos funciones utilizan la macro 'CALLER_ADDR1' (también conocida como __builtin_return_address(1)) para adquirir información de la persona que llama. Si $fp se usa para otro propósito, el código generado en esta macro (como se muestra a continuación) podría provocar una falla de acceso a la memoria. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- error de paginación aquí El mensaje de ups durante el arranque si se compila con el rastreador 'irqoff' habilitado: [ 0.039615][T0] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000f8 [0.041925][T0] Ups [#1] [0.042063][T0] Módulos vinculados en: [0.042864][T0] CPU: 0 PID: 0 Comm : swapper/0 No contaminado 5.17.0-rc1-00233-g9a20c48d1ed2 #29 [ 0.043568][ T0] Nombre de hardware: riscv-virtio,qemu (DT) [ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2 [ 0.044601] [T0] ra: restaurar_all+0x12/0x6e [0.044721][T0] epc: ffffffff80126a5c ra: ffffffff80003b94 sp: ffffffff81403db0 [0.044801][T0] gp: ffffffff8163acd8 tp: ffffffff81414880 t0: 0000000000000020 [0.044882][T0] t1: 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0 [ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100 [ 0.045046][ T0] a2: 0000000000000000 a3: 0000000000000000 a4: 0000000000000000 [0.045124][T0] a5: 00000000000000000 a6: 0000000000000000 a7: 000000 0054494d45 [ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50 [ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00800120e8 [ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 00000000000000000 [ 0.045474][ T0 ] s11: 0000000000000000 t3: 7ffffffffffffff t4: 0000000000000000 [0.045548][T0] t5: 0000000000000000 t6: ffffffff814aa368 [0.045620][T0] 0000000200000100 badaddr: 00000000000000f8 causa: 000000000000000d [ 0.046402][ T0] [] restaurar_todo+ 0x12/0x6e Esto porque el $fp(aka. $s0) el registro no se utiliza como puntero de marco en el código de entrada del ensamblado. resume_kernel: reg_l s0, task_ti_preempt_count (tp) bnez s0, restaure_all reg_l s0, task_ti_flags (tp) andi s0, s0, _tif_need_resched beqz s0, restaure_all call preempt_schedul S_ { on,off}() para que puedan ser llamados de forma segura mediante un código de entrada de bajo nivel.
Vulnerabilidad en kernel de Linux (CVE-2022-48923)
Severidad: Pendiente de análisis
Fecha de publicación: 22/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: evita copiar un segmento lzo comprimido demasiado grande. La longitud comprimida puede corromperse y ser mucho mayor que la memoria que hemos asignado para el búfer. Esto hará que memcpy en copy_compressed_segment escriba fuera de la memoria asignada. Esto principalmente da como resultado una llamada al sistema de lectura bloqueada, pero a veces, cuando se usa el envío btrfs, se puede obtener el kernel #GP: falla de protección general, probablemente para la dirección no canónica 0x841551d5c1000: 0000 [#1] Kernel PREEMPT SMP NOPTI: CPU: 17 PID: 264 Comm: kworker /u256:7 Contaminado: P OE 5.17.0-rc2-1 #12 kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs] kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs /btrfs/lzo.c:322 fs/btrfs/lzo.c:394) Código btrfs que comienza con la instrucción errónea ========================== ================== 0:* 48 8b 06 mov (%rsi),%rax <-- instrucción de captura 3: 48 8d 79 08 lea 0x8(%rcx), %rdi 7: 48 83 e7 f8 y $0xffffffffffffffff8,%rdi b: 48 89 01 mov %rax,(%rcx) e: 44 89 f0 mov %r14d,%eax 11: 48 8b 54 06 f8 mov -0x8(% rsi,%rax,1),%rdx kernel: RSP: 0018:ffffb110812efd50 EFLAGS: 00010212 kernel: RAX: 0000000000001000 RBX: 000000009ca264c8 RCX: ffff98996e6d8ff8 kernel: RDX: 0000000064 RSI: 000841551d5c1000 RDI: ffffffff9500435d kernel: RBP: ffff989a3be856c0 R08: 0000000000000000 R09: 0000000000000000 kernel: R10: 0000000000000000 R11: 0000000000001000 R12: ffff98996e6d8000 kernel: R13: 0000000000000008 R14: 00000000000 01000 R15: 000841551d5c1000 kernel: FS: 0000000000000000(0000) GS:ffff98a09d640000(0000) knlGS:00000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 CR4: 00000000003506e0 kernel: Seguimiento de llamadas: kernel: kernel: end_compressed_bio_read (fs/btrfs/compression.c: 104 fs/btrfs/compression.c:1363 fs /btrfs/compression.c:323) kernel btrfs: end_workqueue_fn (fs/btrfs/disk-io.c:1923) kernel btrfs: btrfs_work_helper (fs/btrfs/async-thread.c:326) kernel btrfs: Process_one_work (./ arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:212 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2312) kernel: trabajador_thread (. /include/linux/list.h:292 kernel/workqueue.c:2455) kernel:? Process_one_work (kernel/workqueue.c:2397) kernel: kthread (kernel/kthread.c:377) kernel:? kthread_complete_and_exit (kernel/kthread.c:332) kernel: ret_from_fork (arch/x86/entry/entry_64.S:301) kernel:
Vulnerabilidad en ContiNew Admin 3.2.0 (CVE-2024-8155)
Severidad: MEDIA
Fecha de publicación: 25/08/2024
Fecha de última actualización: 12/09/2024
Una vulnerabilidad fue encontrada en ContiNew Admin 3.2.0 y clasificada como crítica. La función top.continew.starter.extension.crud.controller.BaseController#tree del archivo /api/system/dept/tree?sort=parentId%2Casc&sort=sort%2Casc es afectada por esta vulnerabilidad. La manipulación del tipo de argumento conduce a la inyección de SQL. El ataque se puede lanzar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.
Vulnerabilidad en kernel de Linux (CVE-2024-44938)
Severidad: Pendiente de análisis
Fecha de publicación: 26/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: corrigió el desplazamiento fuera de los límites en dbDiscardAG Al buscar el siguiente bloque log2 más pequeño, BLKSTOL2() devolvió 0, lo que provocó que el exponente de desplazamiento -1 fuera negativo. Este parche soluciona el problema saliendo del bucle directamente cuando se encuentra un cambio negativo.
Vulnerabilidad en kernel de Linux (CVE-2024-44940)
Severidad: Pendiente de análisis
Fecha de publicación: 26/08/2024
Fecha de última actualización: 12/09/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fou: elimine la advertencia en gue_gro_receive en un protocolo no compatible. Descarte WARN_ON_ONCE en gue_gro_receive si el tipo encapsulado no se conoce o no tiene un controlador GRO. Un paquete de este tipo se construye fácilmente. Syzbot los genera y activa esta advertencia. Elimine la advertencia como se esperaba y no es procesable. La advertencia se redujo previamente de WARN_ON a WARN_ON_ONCE en el commit 270136613bf7 ("fou: Haga WARN_ON_ONCE en gue_gro_receive para devoluciones de llamadas de proto incorrectas").
Vulnerabilidad en Booking for Appointments and Events Calendar – Amelia Premium and Lite para WordPress (CVE-2024-6332)
Severidad: Pendiente de análisis
Fecha de publicación: 05/09/2024
Fecha de última actualización: 12/09/2024
Los complementos Booking for Appointments and Events Calendar – Amelia Premium and Lite para WordPress son vulnerables al acceso no autorizado a los datos debido a una falta de verificación de capacidad en la función 'ameliaButtonCommand' en todas las versiones hasta la Premium 7.7 y la Lite 1.2.3 incluida. Esto permite que atacantes no autenticados accedan a los detalles del calendario de los empleados, incluidos los tokens OAuth de Google Calendar en la versión premium.
Vulnerabilidad en LifterLMS – WP LMS for eLearning, Online Courses, & Quizzes para WordPress (CVE-2024-7349)
Severidad: Pendiente de análisis
Fecha de publicación: 06/09/2024
Fecha de última actualización: 12/09/2024
El complemento LifterLMS – WP LMS for eLearning, Online Courses, & Quizzes para WordPress es vulnerable a la inyección SQL a ciegas a través del parámetro 'order' en todas las versiones hasta la 7.7.5 incluida, debido a un escape insuficiente en el parámetro proporcionado por el usuario y a la falta de preparación suficiente en la consulta SQL existente. Esto permite que los atacantes autenticados, con acceso de nivel de administrador o superior, agreguen consultas SQL adicionales a las consultas ya existentes que se pueden usar para extraer información confidencial de la base de datos.
Vulnerabilidad en WP-Recall – Registration, Profile, Commerce & More para WordPress (CVE-2024-8292)
Severidad: Pendiente de análisis
Fecha de publicación: 06/09/2024
Fecha de última actualización: 12/09/2024
El complemento WP-Recall – Registration, Profile, Commerce & More para WordPress es vulnerable a la escalada de privilegios/apropiación de cuentas en todas las versiones hasta la 16.26.8 incluida. Esto se debe a que el complemento no verifica correctamente la identidad de un usuario durante la creación de un nuevo pedido. Esto hace posible que atacantes no autenticados proporcionen cualquier correo electrónico a través del campo user_email y actualicen la contraseña de ese usuario durante la creación de un nuevo pedido. Esto requiere que el complemento de comercio esté habilitado para poder explotarlo.