Page 291 of 2584 results (0.012 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Do not unset preset when cleaning up codec Several functions that take part in codec's initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component->probe/remove() instead. One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences. As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting ->preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver's module reloading may occur several times throughout the lifetime of an audio stack. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: no desarmar el valor predeterminado al limpiar el códec. • https://git.kernel.org/stable/c/7fc4e7191eae9d9325511e03deadfdb2224914f8 https://git.kernel.org/stable/c/e909f5f2aa55a8f9aa6919cce08015cb0e8d4668 https://git.kernel.org/stable/c/427ca2530da8dc61a42620d7113b05e187b6c2c0 https://git.kernel.org/stable/c/87978e6ad45a16835cc58234451111091be3c59a •

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