Page 394 of 2835 results (0.012 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe() Driver uses kasprintf() to initialize fw_{code,data}_bin members of struct acp_dev_data, but kfree() is never called to deallocate the memory, which results in a memory leak. Fix the issue by switching to devm_kasprintf(). Additionally, ensure the allocation was successful by checking the pointer validity. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: SOF: amd: corrige la pérdida de memoria en amd_sof_acp_probe() El controlador usa kasprintf() para inicializar los miembros fw_{code,data}_bin de la estructura acp_dev_data, pero kfree() nunca se llama para desasignar la memoria, lo que resulta en una pérdida de memoria. Solucione el problema cambiando a devm_kasprintf(). Además, asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero. • https://git.kernel.org/stable/c/f7da88003c53cf0eedabe609324a047b1921dfcc https://git.kernel.org/stable/c/88028c45d5871dfc449b2b0a27abf6428453a5ec https://git.kernel.org/stable/c/be4760799c6a7c01184467287f0de41e0dd255f8 https://git.kernel.org/stable/c/7296152e58858f928db448826eb7ba5ae611297b https://git.kernel.org/stable/c/222be59e5eed1554119294edc743ee548c2371d0 https://access.redhat.com/security/cve/CVE-2023-52663 https://bugzilla.redhat.com/show_bug.cgi?id=2281358 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node When ida_alloc_max fails, resources allocated before should be freed, including *res allocated by kmalloc and ttm_resource_init. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: soluciona un memleak en vmw_gmrid_man_get_node Cuando falla ida_alloc_max, se deben liberar los recursos asignados anteriormente, incluido *res asignado por kmalloc y ttm_resource_init. • https://git.kernel.org/stable/c/d3bcb4b02fe977d6b7a82dbb6288e9223b5b6732 https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5 https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6 https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876 https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce https://access.redhat.com/security/cve/CVE-2023-52662 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe() If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be undone. Add the missing clk_put and a new 'put_pll_d_out0' label in the error handling path, and use it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: rgb: corrige la falta de clk_put() en las rutas de manejo de errores de tegra_dc_rgb_probe(). Si clk_get_sys(..., "pll_d2_out0") falla, la llamada clk_get_sys() debe deshacerse. Agregue el clk_put que falta y una nueva etiqueta 'put_pll_d_out0' en la ruta de manejo de errores y úsela. • https://git.kernel.org/stable/c/0c921b6d4ba06bc899fd84d3ce1c1afd3d00bc1c https://git.kernel.org/stable/c/f3f407ccbe84a34de9be3195d22cdd5969f3fd9f https://git.kernel.org/stable/c/845322a9c06dd1dcf35b6c4e3af89684297c23cc https://git.kernel.org/stable/c/2388c36e028fff7f8ffd515681a14c6c2c07fea7 https://git.kernel.org/stable/c/fa74e4f5d0821829545b9f7034a0e577c205c101 https://git.kernel.org/stable/c/45c8034db47842b25a3ab6139d71e13b4e67b9b3 https://git.kernel.org/stable/c/5c8dc26e31b8b410ad1895e0d314def50c76eed0 https://access.redhat.com/security/cve/CVE-2023-52661 •

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

In the Linux kernel, the following vulnerability has been resolved: block: Fix page refcounts for unaligned buffers in __bio_release_pages() Fix an incorrect number of pages being released for buffers that do not start at the beginning of a page. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloquear: corregidos recuentos de páginas para buffers no alineados en __bio_release_pages() Corrige un número incorrecto de páginas que se liberan para buffers que no comienzan al principio de una página. • https://git.kernel.org/stable/c/9025ee1079291fac79c7fcc20086e9f0015f86f4 https://git.kernel.org/stable/c/8955324cc9f93304efe163120038b38c36c09fba https://git.kernel.org/stable/c/d198c15d181cc9d580f0f2c25150b077d1d49c1a https://git.kernel.org/stable/c/1b151e2435fc3a9b10c8946c6aebe9f3e1938c55 https://git.kernel.org/stable/c/d2d0b95ca1b5fefa3deed444a803c9f809db66cf https://git.kernel.org/stable/c/3f4e660144edb053886fc80f587a71ad7afc2ad6 https://git.kernel.org/stable/c/bfc0647791d7a8f3e178a896a26c4ef7794876b7 https://git.kernel.org/stable/c/0f2dca516541032fe47a1236c852f58ed •

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

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Fix handling of zero block length packets While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero. • https://git.kernel.org/stable/c/ff3ba016263ee93a1c6209bf5ab1599de7ab1512 https://git.kernel.org/stable/c/e7ca00f35d8a17af1ae19d529193ebc21bfda164 https://git.kernel.org/stable/c/17c653d4913bbc50d284aa96cf12bfc63e41ee5c https://git.kernel.org/stable/c/7014807fb7efa169a47a7a0a0a41d2c513925de0 https://git.kernel.org/stable/c/49fbc18378ae72a47feabee97fdb86f3cea09765 https://git.kernel.org/stable/c/427694cfaafa565a3db5c5ea71df6bc095dca92f https://git.kernel.org/stable/c/5bdf93a2f5459f944b416b188178ca4a92fd206f https://git.kernel.org/stable/c/4bf1a9d20c65b9e80ca4b171267103f8d •