CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35838 – wifi: mac80211: fix potential sta-link leak
https://notcve.org/view.php?id=CVE-2024-35838
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential sta-link leak When a station is allocated, links are added but not set to valid yet (e.g. during connection to an AP MLD), we might remove the station without ever marking links valid, and leak them. Fix that. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: corrige una posible fuga de sta-link Cuando se asigna una estación, los enlaces se agregan pero aún no se configuran como válidos (por ejemplo, durante la conexión a un AP MLD), podríamos eliminar la estación sin marcar enlaces válidos y filtrarlos. Arregla eso. • https://git.kernel.org/stable/c/cb71f1d136a635decf43c3b502ee34fb05640fcd https://git.kernel.org/stable/c/49aaeb8c539b1633b3bd7c2df131ec578aa1eae1 https://git.kernel.org/stable/c/587c5892976108674bbe61a8ff659de279318034 https://git.kernel.org/stable/c/e04bf59bdba0fa45d52160be676114e16be855a9 https://git.kernel.org/stable/c/b01a74b3ca6fd51b62c67733ba7c3280fa6c5d26 https://access.redhat.com/security/cve/CVE-2024-35838 https://bugzilla.redhat.com/show_bug.cgi?id=2281157 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35837 – net: mvpp2: clear BM pool before initialization
https://notcve.org/view.php?id=CVE-2024-35837
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: clear BM pool before initialization Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: mvpp2: borre el grupo de BM antes de la inicialización. El valor del registro persiste después de iniciar el kernel usando kexec, lo que genera pánico en el kernel. Por lo tanto, borre los registros del grupo BM antes de la inicialización para solucionar el problema. • https://git.kernel.org/stable/c/3f518509dedc99f0b755d2ce68d24f610e3a005a https://git.kernel.org/stable/c/83f99138bf3b396f761600ab488054396fb5768f https://git.kernel.org/stable/c/af47faa6d3328406038b731794e7cf508c71affa https://git.kernel.org/stable/c/cec65f09c47d8c2d67f2bcad6cf05c490628d1ec https://git.kernel.org/stable/c/938729484cfa535e9987ed0f86f29a2ae3a8188b https://git.kernel.org/stable/c/dc77f6ab5c3759df60ff87ed24f4d45df0f3b4c4 https://git.kernel.org/stable/c/9f538b415db862e74b8c5d3abbccfc1b2b6caa38 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35835 – net/mlx5e: fix a double-free in arfs_create_groups
https://notcve.org/view.php?id=CVE-2024-35835
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a double-free in arfs_create_groups When `in` allocated by kvzalloc fails, arfs_create_groups will free ft->g and return an error. However, arfs_create_table, the only caller of arfs_create_groups, will hold this error and call to mlx5e_destroy_flow_table, in which the ft->g will be freed again. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: corregido un double free en arfs_create_groups Cuando falla `in` asignado por kvzalloc, arfs_create_groups liberará ft->g y devolverá un error. Sin embargo, arfs_create_table, el único llamador de arfs_create_groups, mantendrá este error y llamará a mlx5e_destroy_flow_table, en el que ft->g se liberará nuevamente. A double-free vulnerability was found in the `arfs_create_groups` function in the Linux kernel's `net/mlx5e` driver. • https://git.kernel.org/stable/c/1cabe6b0965ec067ac60e8f182f16d479a3b9a5c https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629 https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7 https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5 https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056 https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7 https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52673 – drm/amd/display: Fix a debugfs null pointer error
https://notcve.org/view.php?id=CVE-2023-52673
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a debugfs null pointer error [WHY & HOW] Check whether get_subvp_en() callback exists before calling it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige un error de puntero null de debugfs [POR QUÉ Y CÓMO] Verifique si la devolución de llamada get_subvp_en() existe antes de llamarla. • https://git.kernel.org/stable/c/43235db21fc23559f50a62f8f273002eeb506f5a https://git.kernel.org/stable/c/efb91fea652a42fcc037d2a9ef4ecd1ffc5ff4b7 •
CVSS: 7.0EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52672 – pipe: wakeup wr_wait after setting max_usage
https://notcve.org/view.php?id=CVE-2023-52672
In the Linux kernel, the following vulnerability has been resolved: pipe: wakeup wr_wait after setting max_usage Commit c73be61cede5 ("pipe: Add general notification queue support") a regression was introduced that would lock up resized pipes under certain conditions. See the reproducer in [1]. The commit resizing the pipe ring size was moved to a different function, doing that moved the wakeup for pipe->wr_wait before actually raising pipe->max_usage. If a pipe was full before the resize occured it would result in the wakeup never actually triggering pipe_write. Set @max_usage and @nr_accounted before waking writers if this isn't a watch queue. [Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tubería: despertar wr_wait después de configurar max_usage Confirmar c73be61cede5 ("tubería: Agregar soporte de cola de notificaciones generales") se introdujo una regresión que bloquearía las tuberías redimensionadas bajo ciertas condiciones. Ver el reproductor en [1]. La confirmación de cambio de tamaño del anillo de tubería se movió a una función diferente, lo que movió la activación de pipe->wr_wait antes de aumentar pipe->max_usage. • https://git.kernel.org/stable/c/c73be61cede5882f9605a852414db559c0ebedfd https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8 https://git.kernel.org/stable/c/3efbd114b91525bb095b8ae046382197d92126b9 https://git.kernel.org/stable/c/b87a1229d8668fbc78ebd9ca0fc797a76001c60f https://git.kernel.org/stable/c/68e51bdb1194f11d3452525b99c98aff6f837b24 https://git.kernel.org/stable/c/6fb70694f8d1ac34e45246b0ac988f025e1e5b55 https://git.kernel.org/stable/c/e95aada4cb93d42e25c30a0ef9eb2923d9711d4a https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-400: Uncontrolled Resource Consumption •