CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27064 – netfilter: nf_tables: Fix a memory leak in nf_tables_updchain
https://notcve.org/view.php?id=CVE-2024-27064
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix a memory leak in nf_tables_updchain If nft_netdev_register_hooks() fails, the memory associated with nft_stats is not freed, causing a memory leak. This patch fixes it by moving nft_stats_alloc() down after nft_netdev_register_hooks() succeeds. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige una pérdida de memoria en nf_tables_updchain Si nft_netdev_register_hooks() falla, la memoria asociada con nft_stats no se libera, lo que provoca una pérdida de memoria. Este parche lo soluciona moviendo nft_stats_alloc() hacia abajo después de que nft_netdev_register_hooks() tenga éxito. • https://git.kernel.org/stable/c/b9703ed44ffbfba85c103b9de01886a225e14b38 https://git.kernel.org/stable/c/d131ce7a319d3bff68d5a9d5509bb22e4ce33946 https://git.kernel.org/stable/c/79846fdcc548d617b0b321addc6a3821d3b75b20 https://git.kernel.org/stable/c/4e4623a4f6e133e671f65f9ac493bddaaf63e250 https://git.kernel.org/stable/c/e77a6b53a3a547b6dedfc40c37cee4f310701090 https://git.kernel.org/stable/c/7eaf837a4eb5f74561e2486972e7f5184b613f6e •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52653 – SUNRPC: fix a memleak in gss_import_v2_context
https://notcve.org/view.php?id=CVE-2023-52653
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix a memleak in gss_import_v2_context The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error. Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: corrige una fuga de memport en gss_import_v2_context El ctx->mech_used.data asignado por kmemdup no se libera ni en gss_import_v2_context ni solo en el llamador gss_krb5_import_sec_context, lo que libera a ctx en caso de error. Por lo tanto, este parche reforma la última llamada de gss_import_v2_context a gss_krb5_import_ctx_v2, evitando la fuga de memoria y manteniendo la formación de retorno. • https://git.kernel.org/stable/c/47d84807762966c3611c38adecec6ea703ddda7a https://git.kernel.org/stable/c/99044c01ed5329e73651c054d8a4baacdbb1a27c https://git.kernel.org/stable/c/47ac11db93e74ac49cd6c3fc69bcbc5964c4a8b4 https://git.kernel.org/stable/c/d111e30d9cd846bb368faf3637dc0f71fcbcf822 https://git.kernel.org/stable/c/e67b652d8e8591d3b1e569dbcdfcee15993e91fa https://access.redhat.com/security/cve/CVE-2023-52653 https://bugzilla.redhat.com/show_bug.cgi?id=2278515 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52652 – NTB: fix possible name leak in ntb_register_device()
https://notcve.org/view.php?id=CVE-2023-52652
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: 0CVE-2022-48669 – powerpc/pseries: Fix potential memleak in papr_get_attr()
https://notcve.org/view.php?id=CVE-2022-48669
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: 0CVE-2024-27063 – leds: trigger: netdev: Fix kernel panic on interface rename trig notify
https://notcve.org/view.php?id=CVE-2024-27063
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 •