Page 85 of 2865 results (0.009 seconds)

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

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

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

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

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 •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup() fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: libfc: corrigió la posible desreferencia del puntero NULL en fc_lport_ptp_setup() fc_lport_ptp_setup() no verificó el valor de retorno de fc_rport_create() que puede devolver NULL y causaría una desreferencia del puntero NULL. Solucione este problema verificando el valor de retorno de fc_rport_create() y el mensaje de error de registro en fc_rport_create() falló. • https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00 https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01 https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34 https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84c • CWE-476: NULL Pointer Dereference •