Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gve: aplazar la habilitación de interrupciones hasta el registro de NAPI<br /> <br /> Actualmente, las interrupciones se habilitan automáticamente inmediatamente después de la solicitud. Esto permite que la interrupción se dispare antes de que el contexto NAPI asociado esté completamente inicializado y cause fallos como los siguientes:<br /> <br /> [ 0.946369] Traza de Llamada:<br /> [ 0.946369] <br /> [ 0.946369] __napi_poll+0x2a/0x1e0<br /> [ 0.946369] net_rx_action+0x2f9/0x3f0<br /> [ 0.946369] handle_softirqs+0xd6/0x2c0<br /> [ 0.946369] ? handle_edge_irq+0xc1/0x1b0<br /> [ 0.946369] __irq_exit_rcu+0xc3/0xe0<br /> [ 0.946369] common_interrupt+0x81/0xa0<br /> [ 0.946369] <br /> [ 0.946369] <br /> [ 0.946369] asm_common_interrupt+0x22/0x40<br /> [ 0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10<br /> <br /> Utilice la bandera &amp;#39;IRQF_NO_AUTOEN&amp;#39; al solicitar interrupciones para evitar la habilitación automática y habilitar explícitamente la interrupción en la ruta de inicialización de NAPI (y deshabilitarla durante la desinstalación de NAPI).<br /> <br /> Esto asegura que el ciclo de vida de la interrupción esté estrictamente acoplado con la disponibilidad del contexto NAPI.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/core: siempre liberar el contador de referencias del dispositivo en ib_del_sub_device_and_put()<br /> <br /> Dado que nldev_deldev() (introducido por el commit 060c642b2ab8 (&amp;#39;RDMA/nldev: Añadir soporte para añadir/eliminar un subdispositivo IB a través de netlink&amp;#39;) obtiene una referencia usando ib_device_get_by_index() antes de llamar a ib_del_sub_device_and_put(), necesitamos liberar esa referencia antes de devolver el error -EOPNOTSUPP.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: properly keep track of conduit reference<br /> <br /> Problem description<br /> -------------------<br /> <br /> DSA has a mumbo-jumbo of reference handling of the conduit net device<br /> and its kobject which, sadly, is just wrong and doesn&amp;#39;t make sense.<br /> <br /> There are two distinct problems.<br /> <br /> 1. The OF path, which uses of_find_net_device_by_node(), never releases<br /> the elevated refcount on the conduit&amp;#39;s kobject. Nominally, the OF and<br /> non-OF paths should result in objects having identical reference<br /> counts taken, and it is already suspicious that<br /> dsa_dev_to_net_device() has a put_device() call which is missing in<br /> dsa_port_parse_of(), but we can actually even verify that an issue<br /> exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command<br /> "before" and "after" applying this patch:<br /> <br /> (unbind the conduit driver for net device eno2)<br /> echo 0000:00:00.2 &gt; /sys/bus/pci/drivers/fsl_enetc/unbind<br /> <br /> we see these lines in the output diff which appear only with the patch<br /> applied:<br /> <br /> kobject: &amp;#39;eno2&amp;#39; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)<br /> kobject: &amp;#39;109&amp;#39; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)<br /> <br /> 2. After we find the conduit interface one way (OF) or another (non-OF),<br /> it can get unregistered at any time, and DSA remains with a long-lived,<br /> but in this case stale, cpu_dp-&gt;conduit pointer. Holding the net<br /> device&amp;#39;s underlying kobject isn&amp;#39;t actually of much help, it just<br /> prevents it from being freed (but we never need that kobject<br /> directly). What helps us to prevent the net device from being<br /> unregistered is the parallel netdev reference mechanism (dev_hold()<br /> and dev_put()).<br /> <br /> Actually we actually use that netdev tracker mechanism implicitly on<br /> user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with<br /> the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().<br /> But time still passes at DSA switch probe time between the initial<br /> of_find_net_device_by_node() code and the user port creation time, time<br /> during which the conduit could unregister itself and DSA wouldn&amp;#39;t know<br /> about it.<br /> <br /> So we have to run of_find_net_device_by_node() under rtnl_lock() to<br /> prevent that from happening, and release the lock only with the netdev<br /> tracker having acquired the reference.<br /> <br /> Do we need to keep the reference until dsa_unregister_switch() /<br /> dsa_switch_shutdown()?<br /> 1: Maybe yes. A switch device will still be registered even if all user<br /> ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not<br /> make user port errors fatal"), and the cpu_dp-&gt;conduit pointers<br /> remain valid. I haven&amp;#39;t audited all call paths to see whether they<br /> will actually use the conduit in lack of any user port, but if they<br /> do, it seems safer to not rely on user ports for that reference.<br /> 2. Definitely yes. We support changing the conduit which a user port is<br /> associated to, and we can get into a situation where we&amp;#39;ve moved all<br /> user ports away from a conduit, thus no longer hold any reference to<br /> it via the net device tracker. But we shouldn&amp;#39;t let it go nonetheless<br /> - see the next change in relation to dsa_tree_find_first_conduit()<br /> and LAG conduits which disappear.<br /> We have to be prepared to return to the physical conduit, so the CPU<br /> port must explicitly keep another reference to it. This is also to<br /> say: the user ports and their CPU ports may not always keep a<br /> reference to the same conduit net device, and both are needed.<br /> <br /> As for the conduit&amp;#39;s kobject for the /sys/class/net/ entry, we don&amp;#39;t<br /> care about it, we can release it as soon as we hold the net device<br /> object itself.<br /> <br /> History and blame attribution<br /> -----------------------------<br /> <br /> The code has been refactored so many times, it is very difficult to<br /> follow and properly attribute a blame, but I&amp;#39;ll try to make a short<br /> history which I hope to be correct.<br /> <br /> We have two distinct probing paths:<br /> - one for OF, introduced in 2016 i<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: nf_conncount: corrección de &amp;#39;ct&amp;#39; filtrado en rutas de error<br /> <br /> Existen algunas situaciones en las que &amp;#39;ct&amp;#39; podría filtrarse, ya que las rutas de error están omitiendo la verificación de conteo de referencias y retornan inmediatamente. Para resolverlo, hay que asegurarse de que la verificación siempre sea llamada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> KEYS: trusted: Corregir una fuga de memoria en tpm2_load_cmd<br /> <br /> &amp;#39;tpm2_load_cmd&amp;#39; asigna un blob temporal indirectamente a través de &amp;#39;tpm2_key_decode&amp;#39; pero no se libera en las rutas de fallo. Esto se aborda envolviendo el blob con una función auxiliar de limpieza.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/handshake: restaurar destructor en fallo de envío<br /> <br /> handshake_req_submit() reemplaza sk-&amp;gt;sk_destruct pero nunca lo restaura cuando el envío falla antes de que la solicitud sea hasheada. handshake_sk_destruct() entonces retorna prematuramente y el destructor original nunca se ejecuta, fugando el socket. Restaurar sk_destruct en la ruta de error.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cifs: Corrección de fuga de memoria e información en smb3_reconfigure()<br /> <br /> En smb3_reconfigure(), si smb3_sync_session_ctx_passwords() falla, la función retorna inmediatamente sin liberar y borrar los recién asignados new_password y new_password2. Esto causa tanto una fuga de memoria como una potencial fuga de información.<br /> <br /> Esto se corrige llamando a kfree_sensitive() en ambos búferes de contraseña antes de retornar en este caso de error.

Existe una vulnerabilidad de revelación de información no autenticada en Newgen OmniDocs debido a la falta de autenticación y control de acceso en el endpoint de la API /omnidocs/GetListofCabinet. Un atacante remoto puede acceder a este endpoint sin credenciales válidas para recuperar información de configuración interna sensible, incluyendo nombres de gabinetes y metadatos relacionados con la base de datos. Esto permite la enumeración no autorizada de detalles de despliegue del backend y puede facilitar ataques dirigidos adicionales.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: Soluciona la fuga de contador de referencias cuando se encuentra una sesión inválida en la búsqueda de sesión<br /> <br /> Cuando se encuentra una sesión pero su estado no es SMB2_SESSION_VALID, indica que no se encontró ninguna sesión válida, pero falta decrementar el contador de referencias adquirido por la búsqueda de sesión, lo que resulta en una fuga de contador de referencias. Este parche soluciona el problema llamando explícitamente a ksmbd_user_session_put para liberar la referencia a la sesión.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> io_uring/poll: manejar correctamente el valor de retorno de io_poll_add() en la actualización<br /> <br /> Cuando el núcleo de io_uring fue actualizado para manejar las finalizaciones de manera consistente y con códigos de retorno fijos, el código de operación POLL_REMOVE con actualizaciones se rompió ligeramente. Si un POLL_ADD está pendiente y luego se usa POLL_REMOVE para actualizar los eventos de esa solicitud, si esa actualización hace que el POLL_ADD se active ahora, entonces esa finalización se pierde y nunca se publica un CQE.<br /> <br /> Además, asegúrese de que si una actualización causa que un POLL_ADD existente se complete, que el valor de finalización no siempre sea sobrescrito con -ECANCELED. Para ese caso, lo que sea que io_poll_add() haya establecido el valor debería simplemente ser retenido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> usb: phy: isp1301: corregir desequilibrio de referencia de dispositivo no-OF<br /> <br /> Un cambio reciente que corregía una fuga de referencia de dispositivo en un controlador UDC introdujo un potencial uso después de liberación en el caso no-OF, ya que la función auxiliar isp1301_get_client() solo incrementa el contador de referencias para el dispositivo I2C devuelto en el caso OF.<br /> <br /> Incrementar el contador de referencias también para no-OF para que el llamador pueda decrementarlo incondicionalmente.<br /> <br /> Tenga en cuenta que esto es inherentemente propenso a condiciones de carrera, al igual que lo es usar el dispositivo I2C devuelto, ya que nada impide que el controlador PHY sea desvinculado mientras está en uso.

El plugin weDocs: AI Powered Knowledge Base, Docs, Documentation, Wiki &amp;amp; AI Chatbot para WordPress es vulnerable a la modificación o pérdida de datos no autorizada debido a una falta de verificación de capacidad en la función &amp;#39;wedocs_user_documentation_handling_capabilities&amp;#39; en todas las versiones hasta la 2.1.16, inclusive. Esto hace posible que atacantes autenticados, con acceso de nivel Suscriptor y superior, editen cualquier publicación de documentación. La vulnerabilidad fue parcheada parcialmente en la versión 2.1.16.