Page 255 of 1471 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: NTB: fix possible name leak in ntb_register_device() If device_register() fails in ntb_register_device(), the device name allocated by dev_set_name() should be freed. As per the comment in device_register(), callers should use put_device() to give up the reference in the error path. So fix this by calling put_device() in the error path so that the name can be freed in kobject_cleanup(). As a result of this, put_device() in the error path of ntb_register_device() is removed and the actual error is returned. [mani: reworded commit message] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NTB: corrige una posible fuga de nombre en ntb_register_device() Si device_register() falla en ntb_register_device(), se debe liberar el nombre del dispositivo asignado por dev_set_name(). Según el comentario en device_register(), las personas que llaman deben usar put_device() para abandonar la referencia en la ruta de error. Así que solucione este problema llamando a put_device() en la ruta del error para que el nombre pueda liberarse en kobject_cleanup(). • https://git.kernel.org/stable/c/a1bd3baeb2f18b2b3d0f98ce5fdaa725149b950b https://git.kernel.org/stable/c/a62b9f3d7bbfac874cc0c638bc1776dcf1f8ec06 https://git.kernel.org/stable/c/6632a54ac8057cc0b0d789c6f73883e871bcd25c https://git.kernel.org/stable/c/a039690d323221eb5865f1f31db3ec264e7a14b6 https://git.kernel.org/stable/c/e8025439ef8e16029dc313d78a351ef192469b7b https://git.kernel.org/stable/c/913421f9f7fd8324dcc41753d0f28b52e177ef04 https://git.kernel.org/stable/c/aebfdfe39b9327a3077d0df8db3beb3160c9bdd0 •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix potential memleak in papr_get_attr() `buf` is allocated in papr_get_attr(), and krealloc() of `buf` could fail. We need to free the original `buf` in the case of failure. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/pseries: corrija una posible fuga de mem en papr_get_attr() `buf` está asignado en papr_get_attr(), y krealloc() de `buf` podría fallar. Necesitamos liberar el "buf" original en caso de falla. A flaw was found in the Linux kernel. • https://git.kernel.org/stable/c/3c14b73454cf9f6e2146443fdfbdfb912c0efed3 https://git.kernel.org/stable/c/a3f22feb2220a945d1c3282e34199e8bcdc5afc4 https://git.kernel.org/stable/c/1699fb915b9f61794d559b55114c09a390aaf234 https://git.kernel.org/stable/c/7f7d39fe3d80d6143404940b2413010cf6527029 https://git.kernel.org/stable/c/d0647c3e81eff62b66d46fd4e475318cb8cb3610 https://git.kernel.org/stable/c/cda9c0d556283e2d4adaa9960b2dc19b16156bae https://access.redhat.com/security/cve/CVE-2022-48669 https://bugzilla.redhat.com/show_bug.cgi?id=2278537 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: leds: trigger: netdev: Fix kernel panic on interface rename trig notify Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") in the various changes, reworked the way to set the LINKUP mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function. This changed the logic where, in the previous implementation the dev from the trigger event was used to check if the carrier was ok, but in the new implementation with the generic function, the dev in trigger_data is used instead. This is problematic and cause a possible kernel panic due to the fact that the dev in the trigger_data still reference the old one as the new one (passed from the trigger event) still has to be hold and saved in the trigger_data struct (done in the NETDEV_REGISTER case). On calling of get_device_state(), an invalid net_dev is used and this cause a kernel panic. To handle this correctly, move the call to get_device_state() after the new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER case) and correctly parse the new dev. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: leds: trigger: netdev: corrige el pánico del kernel al cambiar el nombre de la interfaz, notifica el trigono. Commit d5e01266e7f5 ("leds: trigger: netdev: agrega un modo de velocidad de enlace específico adicional") en los diversos cambios, reelaborados la forma de configurar el modo LINKUP en el commit cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") y lo moví a una función genérica. Esto cambió la lógica donde, en la implementación anterior, se usaba el desarrollo del evento desencadenante para verificar si el operador estaba bien, pero en la nueva implementación con la función genérica, se usa el desarrollo en trigger_data. Esto es problemático y causa un posible pánico en el kernel debido al hecho de que el desarrollador en trigger_data aún hace referencia al anterior, ya que el nuevo (pasado desde el evento desencadenante) aún debe retenerse y guardarse en la estructura trigger_data (hecho en el caso NETDEV_REGISTER). • https://git.kernel.org/stable/c/d5e01266e7f5fa12400d4c8aa4e86fe89dcc61e9 https://git.kernel.org/stable/c/10f2af1af8ab8a7064f193446abd5579d3def7e3 https://git.kernel.org/stable/c/acd025c7a7d151261533016a6ca2d38f2de04e87 https://git.kernel.org/stable/c/3f360227cb46edb2cd2494128e1e06ed5768a62e https://git.kernel.org/stable/c/415798bc07dd1c1ae3a656aa026580816e0b9fe8 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: tmpfs: fix race on handling dquot rbtree A syzkaller reproducer found a race while attempting to remove dquot information from the rb tree. Fetching the rb_tree root node must also be protected by the dqopt->dqio_sem, otherwise, giving the right timing, shmem_release_dquot() will trigger a warning because it couldn't find a node in the tree, when the real reason was the root node changing before the search starts: Thread 1 Thread 2 - shmem_release_dquot() - shmem_{acquire,release}_dquot() - fetch ROOT - Fetch ROOT - acquire dqio_sem - wait dqio_sem - do something, triger a tree rebalance - release dqio_sem - acquire dqio_sem - start searching for the node, but from the wrong location, missing the node, and triggering a warning. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tmpfs: corrige la ejecución al manejar dquot rbtree Un reproductor syzkaller encontró una ejecución al intentar eliminar información de dquot del árbol rb. La recuperación del nodo raíz de rb_tree también debe estar protegida por dqopt->dqio_sem; de lo contrario, si se da el momento adecuado, shmem_release_dquot() activará una advertencia porque no pudo encontrar un nodo en el árbol, cuando la verdadera razón era el nodo raíz. cambiando antes de que comience la búsqueda: Hilo 1 Hilo 2 - shmem_release_dquot() - shmem_{acquire,release}_dquot() - buscar ROOT - Obtener ROOT - adquirir dqio_sem - esperar dqio_sem - hacer algo, activar un reequilibrio de árbol - liberar dqio_sem - adquirir dqio_sem - comienza a buscar el nodo, pero desde la ubicación incorrecta, pierde el nodo y genera una advertencia. • https://git.kernel.org/stable/c/eafc474e202978ac735c551d5ee1eb8c02e2be54 https://git.kernel.org/stable/c/c7077f43f30d817d10a9f8245e51576ac114b2f0 https://git.kernel.org/stable/c/617d55b90e73c7b4aa2733ca6cc3f9b72d1124bb https://git.kernel.org/stable/c/f82f184874d2761ebaa60dccf577921a0dbb3810 https://git.kernel.org/stable/c/0a69b6b3a026543bc215ccc866d0aea5579e6ce2 •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix double module refcount decrement Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: corrige la disminución del doble recuento del módulo Una vez que la disciplina está asociada con el dispositivo, eliminar el dispositivo se encarga de disminuir el recuento del módulo. Hacerlo manualmente en esta ruta de error hace que el recuento disminuya artificialmente en cada error, mientras que debería permanecer igual. • https://git.kernel.org/stable/c/c020d722b110a44c613ef71e657e6dd4116e09d9 https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19 https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650 https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5 https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06 •