Page 451 of 3898 results (0.016 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: io_uring/net: fix overflow check in io_recvmsg_mshot_prep() The "controllen" variable is type size_t (unsigned long). Casting it to int could lead to an integer underflow. The check_add_overflow() function considers the type of the destination which is type int. If we add two positive values and the result cannot fit in an integer then that's counted as an overflow. However, if we cast "controllen" to an int and it turns negative, then negative values *can* fit into an int type so there is no overflow. Good: 100 + (unsigned long)-4 = 96 <-- overflow Bad: 100 + (int)-4 = 96 <-- no overflow I deleted the cast of the sizeof() as well. That's not a bug but the cast is unnecessary. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/net: corregida la comprobación de desbordamiento en io_recvmsg_mshot_prep() La variable "controllen" es de tipo size_t (largo sin firmar). • https://git.kernel.org/stable/c/9b0fc3c054ff2eb13753104884f1045b5bb3a627 https://git.kernel.org/stable/c/868ec868616438df487b9e2baa5a99f8662cc47c https://git.kernel.org/stable/c/59a534690ecc3af72c6ab121aeac1237a4adae66 https://git.kernel.org/stable/c/0c8c74bb59e7d77554016efc34c2d10376985e5e https://git.kernel.org/stable/c/b6563ad0d599110bd5cf8f56c47d279c3ed796fe https://git.kernel.org/stable/c/8ede3db5061bb1fe28e2c9683329aafa89d2b1b4 •

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: -EPSS: 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 •

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 •