CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47144 – drm/amd/amdgpu: fix refcount leak
https://notcve.org/view.php?id=CVE-2021-47144
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: fix refcount leak [Why] the gem object rfb->base.obj[0] is get according to num_planes in amdgpufb_create, but is not put according to num_planes [How] put rfb->base.obj[0] in amdgpu_fbdev_destroy according to num_planes En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/amdgpu: corrige la fuga de refcount [Por qué] el objeto gema rfb->base.obj[0] se obtiene según num_planes en amdgpufb_create, pero no se coloca según num_planes en amdgpufb_create num_planes [Cómo] poner rfb->base.obj[0] en amdgpu_fbdev_destroy según num_planes • https://git.kernel.org/stable/c/599e5d61ace952b0bb9bd942b198bbd0cfded1d7 https://git.kernel.org/stable/c/dde2656e0bbb2ac7d83a7bd95a8d5c3c95bbc009 https://git.kernel.org/stable/c/9fdb8ed37a3a44f9c49372b69f87fd5f61cb3240 https://git.kernel.org/stable/c/95a4ec905e51a30c64cf2d78b04a7acbeae5ca94 https://git.kernel.org/stable/c/fa7e6abc75f3d491bc561734312d065dc9dc2a77 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47142 – drm/amdgpu: Fix a use-after-free
https://notcve.org/view.php?id=CVE-2021-47142
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix a use-after-free looks like we forget to set ttm->sg to NULL. Hit panic below [ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 1235.989074] Call Trace: [ 1235.991751] sg_free_table+0x17/0x20 [ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: se soluciona un problema de use-after-free que parece que nos olvidamos de configurar ttm->sg en NULL. Se produce pánico a continuación [1235.844104] falla de protección general, probablemente para la dirección no canónica 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [1235.989074] Seguimiento de llamadas: [1235.991751] sg_free_table+0x17/0x20 [ 123 5.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa 0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 123 6.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [ amdgpu] • https://git.kernel.org/stable/c/0707c3fea8102d211631ba515ef2159707561b0d https://git.kernel.org/stable/c/3293cf3513d69f00c14d43e2020826d45ea0e46a https://git.kernel.org/stable/c/952ab3f9f48eb0e8050596d41951cf516be6b122 https://git.kernel.org/stable/c/a849e218556f932576c0fb1c5a88714b61709a17 https://git.kernel.org/stable/c/7398c2aab4da960761ec182d04d6d5abbb4a226e https://git.kernel.org/stable/c/f98cdf084405333ee2f5be548a91b2d168e49276 https://git.kernel.org/stable/c/d4ea141fd4b40636a8326df5a377d9c5cf9b3faa https://git.kernel.org/stable/c/1e5c37385097c35911b0f8a0c67ffd10e •
CVSS: 2.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52620 – netfilter: nf_tables: disallow timeout for anonymous sets
https://notcve.org/view.php?id=CVE-2023-52620
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow timeout for anonymous sets Never used from userspace, disallow these parameters. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: no permite el tiempo de espera para conjuntos anónimos Nunca se usa desde el espacio de usuario, no permita estos parámetros. A vulnerability was found in netfilter/nf_tables componets of Linux Kernel allows an userspace to set timeouts for anonymous sets, which are not intended to be used this way. This could lead to unexpected behaviour or security issues. • https://git.kernel.org/stable/c/116b0e8e4673a5faa8a739a19b467010c4d3058c https://git.kernel.org/stable/c/49ce99ae43314d887153e07cec8bb6a647a19268 https://git.kernel.org/stable/c/6f3ae02bbb62f151b19162d5fdc9fe3d48450323 https://git.kernel.org/stable/c/00b19ee0dcc1aef06294471ab489bae26d94524e https://git.kernel.org/stable/c/b7be6c737a179a76901c872f6b4c1d00552d9a1b https://git.kernel.org/stable/c/e26d3009efda338f19016df4175f354a9bd0a4ab https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://lists.debian.org/debian-lts-announce/2024&# • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52619 – pstore/ram: Fix crash when setting number of cpus to an odd number
https://notcve.org/view.php?id=CVE-2023-52619
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pstore/ram: soluciona el fallo al establecer el número de CPU en un número impar. Cuando el número de núcleos de CPU se ajusta a 7 u otros números impares, el tamaño de la zona se convertirá en un número impar. La dirección de la zona se convertirá en: dirección de zona0 = BASE dirección de zona1 = BASE + tamaño_zona dirección de zona2 = BASE + tamaño_zona*2 ... La dirección de zona1/3/5/7 se asignará a va no alineada . • https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4 https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10 https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542 https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52618 – block/rnbd-srv: Check for unlikely string overflow
https://notcve.org/view.php?id=CVE-2023-52618
In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: block/rnbd-srv: Comprueba si hay un desbordamiento de cadena improbable. Dado que "dev_search_path" técnicamente puede ser tan grande como PATH_MAX, existía el riesgo de truncamiento al copiarlo y una segunda cadena en " full_path" ya que también tenía un tamaño PATH_MAX. Las compilaciones W=1 informaban esta advertencia: drivers/block/rnbd/rnbd-srv.c: En función 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: advertencia: '% La salida de la directiva s se puede truncar escribiendo hasta 254 bytes en una región de tamaño entre 0 y 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ En la función 'rnbd_srv_get_full_path', insertada desde 'process_msg_open.isra' en drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block /rnbd/rnbd-srv.c:616:17: nota: 'snprintf' genera entre 2 y 4351 bytes en un destino de tamaño 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~ ~~~~~~~~~~~~~~~~~~~ Para solucionar este problema, verifique incondicionalmente el truncamiento (como ya se hizo en el caso en el que "%SESSNAME%" estaba presente). • https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7 https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7 https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827 https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339 https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •