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 https://access.redhat.com/security/cve/CVE-2023-52814 https://bugzilla.redhat.com/show_bug.cgi?id=2282655 • 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 •
CVSS: 8.4EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52810 – fs/jfs: Add check for negative db_l2nbperpage
https://notcve.org/view.php?id=CVE-2023-52810
In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Add check for negative db_l2nbperpage l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative. In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent. Syzbot reported this bug: UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/jfs: agregue verificación para db_l2nbperpage negativo, l2nbperpage es log2 (número de bloques por página) y el valor mínimo legal debe ser 0, no negativo. En el caso de que l2nbperpage sea negativo, se producirá un error cuando se utilice posteriormente como exponente de desplazamiento. Syzbot informó este error: UBSAN: desplazamiento fuera de los límites en fs/jfs/jfs_dmap.c:799:12 el exponente de desplazamiento -16777216 es negativo • https://git.kernel.org/stable/c/cc61fcf7d1c99f148fe8ddfb5c6ed0bb75861f01 https://git.kernel.org/stable/c/8f2964df6bfce9d92d81ca552010b8677af8d9dc https://git.kernel.org/stable/c/a81a56b4cbe3142cc99f6b98e8f9b3a631c768e1 https://git.kernel.org/stable/c/524b4f203afcf87accfe387e846f33f916f0c907 https://git.kernel.org/stable/c/5f148b16972e5f4592629b244d5109b15135f53f https://git.kernel.org/stable/c/0cb567e727339a192f9fd0db00781d73a91d15a6 https://git.kernel.org/stable/c/491085258185ffc4fb91555b0dba895fe7656a45 https://git.kernel.org/stable/c/1a7c53fdea1d189087544d9a606d249e9 • CWE-1335: Incorrect Bitwise Shift of Integer •