Page 271 of 2345 results (0.008 seconds)

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

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: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: xsk: recycle buffer in case Rx queue was full Add missing xsk_buff_free() call when __xsk_rcv_zc() failed to produce descriptor to XSK Rx queue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xsk: reciclar búfer en caso de que la cola Rx estuviera llena. Agregue la llamada xsk_buff_free() faltante cuando __xsk_rcv_zc() falla al generar un descriptor en la cola XSK Rx. • https://git.kernel.org/stable/c/24ea50127ecf0efe819c1f6230add27abc6ca9d9 https://git.kernel.org/stable/c/cce713664548284daf977739e7ff1cd59e84189c https://git.kernel.org/stable/c/7b4d93d31aade99210d41cd9d4cbd2957c98bc8c https://git.kernel.org/stable/c/269009893146c495f41e9572dd9319e787c2eba9 •

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

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: 0

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-&gt;wr_wait antes de aumentar pipe-&gt;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 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix hang/underflow when transitioning to ODM4:1 [Why] Under some circumstances, disabling an OPTC and attempting to reclaim its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs not being properly disconnected from the disabled OPTC. [How] Ensure that all OPPs are unassigned from an OPTC when it gets disabled. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrigió bloqueo/desbordamiento insuficiente al realizar la transición a ODM4:1 [Por qué] En algunas circunstancias, deshabilitar un OPTC e intentar reclamar sus OPP para otro OPTC podría causar un bloqueo/desbordamiento insuficiente debido a que los OPP no se desconectan correctamente del OPTC deshabilitado. [Cómo] Asegúrese de que todos los OPP estén desasignados de un OPTC cuando se deshabilite. • https://git.kernel.org/stable/c/ae62f1dde66a6f0eee98defc4c7a346bd5acd239 https://git.kernel.org/stable/c/4b6b479b2da6badff099b2e3abf0248936eefbf5 https://git.kernel.org/stable/c/e7b2b108cdeab76a7e7324459e50b0c1214c0386 •