CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52815 – drm/amdgpu/vkms: fix a possible null pointer dereference
https://notcve.org/view.php?id=CVE-2023-52815
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vkms: fix a possible null pointer dereference In amdgpu_vkms_conn_get_modes(), the return value of drm_cvt_mode() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_cvt_mode(). Add a check to avoid null pointer dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu/vkms: soluciona una posible desreferencia del puntero null. En amdgpu_vkms_conn_get_modes(), el valor de retorno de drm_cvt_mode() se asigna al modo, lo que provocará una desreferencia del puntero NULL en falla de drm_cvt_mode(). Agregue una marca para evitar la desreferencia del puntero null. • https://git.kernel.org/stable/c/eaa03ea366c85ae3cb69c8d4bbc67c8bc2167a27 https://git.kernel.org/stable/c/33fb1a555354bd593f785935ddcb5d9dd4d3847f https://git.kernel.org/stable/c/8c6c85a073768df68c1a3fea143d013a38c66d34 https://git.kernel.org/stable/c/70f831f21155c692bb336c434936fd6f24f3f81a https://git.kernel.org/stable/c/cd90511557fdfb394bb4ac4c3b539b007383914c • CWE-476: NULL Pointer Dereference •
CVSS: 9.1EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52814 – drm/amdgpu: Fix potential null pointer derefernce
https://notcve.org/view.php?id=CVE-2023-52814
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential null pointer derefernce The amdgpu_ras_get_context may return NULL if device not support ras feature, so add check before using. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: soluciona una posible desreferencia del puntero null. Amdgpu_ras_get_context puede devolver NULL si el dispositivo no admite la función ras, así que agregue la verificación antes de usarlo. • https://git.kernel.org/stable/c/b93a25de28af153312f0fc979b0663fc4bd3442b https://git.kernel.org/stable/c/c11cf5e117f50f5a767054600885acd981449afe https://git.kernel.org/stable/c/9b70fc7d70e8ef7c4a65034c9487f58609e708a1 https://git.kernel.org/stable/c/b0702ee4d811708251cdf54d4a1d3e888d365111 https://git.kernel.org/stable/c/da46e63482fdc5e35c008865c22ac64027f6f0c2 https://git.kernel.org/stable/c/80285ae1ec8717b597b20de38866c29d84d321a1 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52813 – crypto: pcrypt - Fix hungtask for PADATA_RESET
https://notcve.org/view.php?id=CVE-2023-52813
In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix hungtask for PADATA_RESET We found a hungtask bug in test_aead_vec_cfg as follows: INFO: task cryptomgr_test:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks For padata_do_parallel, when the return err is 0 or -EBUSY, it will call wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal case, aead_request_complete() will be called in pcrypt_aead_serial and the return err is 0 for padata_do_parallel. But, when pinst->flags is PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it won't call aead_request_complete(). Therefore, test_aead_vec_cfg will hung at wait_for_completion(&wait->completion), which will cause hungtask. The problem comes as following: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again. v3: remove retry and just change the return err. v2: introduce padata_try_do_parallel() in pcrypt_aead_encrypt and pcrypt_aead_decrypt to solve the hungtask. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: pcrypt - Reparar hungtask para PADATA_RESET. • https://git.kernel.org/stable/c/fb2d3a50a8f29a3c66682bb426144f40e32ab818 https://git.kernel.org/stable/c/039fec48e062504f14845124a1a25eb199b2ddc0 https://git.kernel.org/stable/c/c9c1334697301c10e6918d747ed38abfbc0c96e7 https://git.kernel.org/stable/c/e97bf4ada7dddacd184c3e196bd063b0dc71b41d https://git.kernel.org/stable/c/546c1796ad1ed0d87dab3c4b5156d75819be2316 https://git.kernel.org/stable/c/c55fc098fd9d2dca475b82d00ffbcaf97879d77e https://git.kernel.org/stable/c/e134f3aba98e6c801a693f540912c2d493718ddf https://git.kernel.org/stable/c/372636debe852913529b1716f44addd94 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52812 – drm/amd: check num of link levels when update pcie param
https://notcve.org/view.php?id=CVE-2023-52812
In the Linux kernel, the following vulnerability has been resolved: drm/amd: check num of link levels when update pcie param In SR-IOV environment, the value of pcie_table->num_of_link_levels will be 0, and num_of_levels - 1 will cause array index out of bounds En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd: comprueba el número de niveles de enlace cuando se actualiza el parámetro pcie. En el entorno SR-IOV, el valor de pcie_table->num_of_link_levels será 0, y num_of_levels - 1 provocará un índice de matriz fuera de los límites. • https://git.kernel.org/stable/c/5b4574b663d0a1a0a62d5232429b7db9ae6d0670 https://git.kernel.org/stable/c/09f617219fe9ccd8d7b65dc3e879b5889f663b5a https://git.kernel.org/stable/c/406e8845356d18bdf3d3a23b347faf67706472ec •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52811 – scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool
https://notcve.org/view.php?id=CVE-2023-52811
In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool In practice the driver should never send more commands than are allocated to a queue's event pool. In the unlikely event that this happens, the code asserts a BUG_ON, and in the case that the kernel is not configured to crash on panic returns a junk event pointer from the empty event list causing things to spiral from there. This BUG_ON is a historical artifact of the ibmvfc driver first being upstreamed, and it is well known now that the use of BUG_ON is bad practice except in the most unrecoverable scenario. There is nothing about this scenario that prevents the driver from recovering and carrying on. Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL pointer in the case of an empty event pool. Update all call sites to ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate failure or recovery action. • https://git.kernel.org/stable/c/e1d1f79b1929dce470a5dc9281c574cd58e8c6c0 https://git.kernel.org/stable/c/88984ec4792766df5a9de7a2ff2b5f281f94c7d4 https://git.kernel.org/stable/c/d2af4ef80601224b90630c1ddc7cd2c7c8ab4dd8 https://git.kernel.org/stable/c/8bbe784c2ff28d56ca0c548aaf3e584edc77052d https://git.kernel.org/stable/c/b39f2d10b86d0af353ea339e5815820026bca48f https://access.redhat.com/security/cve/CVE-2023-52811 https://bugzilla.redhat.com/show_bug.cgi?id=2282743 • CWE-476: NULL Pointer Dereference •