Page 383 of 3289 results (0.010 seconds)

CVSS: 9.1EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: no permita que sock_map_{close,destroy,unhash} se llame a sí mismo. Las devoluciones de llamada del proto sock_map nunca deberían llamarse a sí mismas por diseño. Protéjase contra bugs como [1] y salga del bucle recursivo para evitar un desbordamiento de la pila que favorezca una fuga de recursos. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ • https://git.kernel.org/stable/c/f312367f5246e04df564d341044286e9e37a97ba https://git.kernel.org/stable/c/7499859881488da97589f3c79cc66fa75748ad49 https://git.kernel.org/stable/c/5b4a79ba65a1ab479903fff2e604865d229b70a9 https://access.redhat.com/security/cve/CVE-2023-52735 https://bugzilla.redhat.com/show_bug.cgi?id=2282618 • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •

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

In the Linux kernel, the following vulnerability has been resolved: s390/decompressor: specify __decompress() buf len to avoid overflow Historically calls to __decompress() didn't specify "out_len" parameter on many architectures including s390, expecting that no writes beyond uncompressed kernel image are performed. This has changed since commit 2aa14b1ab2c4 ("zstd: import usptream v1.5.2") which includes zstd library commit 6a7ede3dfccb ("Reduce size of dctx by reutilizing dst buffer (#2751)"). Now zstd decompression code might store literal buffer in the unwritten portion of the destination buffer. Since "out_len" is not set, it is considered to be unlimited and hence free to use for optimization needs. On s390 this might corrupt initrd or ipl report which are often placed right after the decompressor buffer. • https://git.kernel.org/stable/c/16409f7d9ca5bb8220e1049ea9aae0d3c94d2dfb https://git.kernel.org/stable/c/55dbd6f4ea954751340f4f73d5dcd7c8f12208b2 https://git.kernel.org/stable/c/9ed522143f959630f8b7782ddc212900d8f609a9 https://git.kernel.org/stable/c/f1eb22d0ff064ad458b3b1a1eaa84ac3996206c2 https://git.kernel.org/stable/c/7ab41c2c08a32132ba8c14624910e2fe8ce4ba4b • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •

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

In the Linux kernel, the following vulnerability has been resolved: ceph: blocklist the kclient when receiving corrupted snap trace When received corrupted snap trace we don't know what exactly has happened in MDS side. And we shouldn't continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents. This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself. The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: lista de bloqueo del kclient cuando se recibe un seguimiento instantáneo corrupto. Cuando recibimos un seguimiento instantáneo corrupto, no sabemos qué ha sucedido exactamente en el lado MDS. Y no debemos continuar con el acceso de IO y metadatos a MDS, lo que puede dañar u obtener contenidos incorrectos. • https://git.kernel.org/stable/c/66ec619e4591f8350f99c5269a7ce160cccc7a7c https://git.kernel.org/stable/c/a68e564adcaa69b0930809fb64d9d5f7d9c32ba9 •

CVSS: 4.4EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix invalid page access after closing deferred I/O devices When a fbdev with deferred I/O is once opened and closed, the dirty pages still remain queued in the pageref list, and eventually later those may be processed in the delayed work. This may lead to a corruption of pages, hitting an Oops. This patch makes sure to cancel the delayed work and clean up the pageref list at closing the device for addressing the bug. A part of the cleanup code is factored out as a new helper function that is called from the common fb_release(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: corrige el acceso a páginas no válidas después de cerrar dispositivos de E/S diferidas. Cuando un fbdev con E/S diferidas se abre y cierra una vez, las páginas sucias aún permanecen en cola en la lista pageref. y, eventualmente, más adelante, podrán procesarse en el trabajo retrasado. • https://git.kernel.org/stable/c/56c134f7f1b58be08bdb0ca8372474a4a5165f31 https://git.kernel.org/stable/c/f1d91f0e9d5a240a809698d7d9c5a538e7dcc149 https://git.kernel.org/stable/c/3efc61d95259956db25347e2a9562c3e54546e20 https://git.kernel.org/stable/c/87b9802ca824fcee7915e717e9a60471af62e8e9 https://access.redhat.com/security/cve/CVE-2023-52731 https://bugzilla.redhat.com/show_bug.cgi?id=2282787 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •

CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: mmc: sdio: fix possible resource leaks in some error paths If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device(). To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device(). In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced. Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone. unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: sdio: soluciona posibles fugas de recursos en algunas rutas de error. • https://git.kernel.org/stable/c/3d10a1ba0d37c8f5fd5afcdda00613fbb8a90bf5 https://git.kernel.org/stable/c/92ff03c2563c9b57a027c744750f3b7d2f261c58 https://git.kernel.org/stable/c/5c7858adada31dbed042448cff6997dd6efc472a https://git.kernel.org/stable/c/761db46b29b496946046d8cb33c7ea6de6bef36e https://git.kernel.org/stable/c/30716d9f0fa1766e522cf24c8a456244e4fc9931 https://git.kernel.org/stable/c/1e06cf04239e202248c8fa356bf11449dc73cfbd https://git.kernel.org/stable/c/f855d31bb38d663c3ba672345d7cce9324ba3b72 https://git.kernel.org/stable/c/605d9fb9556f8f5fb4566f4df1480f280 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •