CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52736 – ALSA: hda: Do not unset preset when cleaning up codec
https://notcve.org/view.php?id=CVE-2023-52736
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: 0CVE-2023-52735 – bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself
https://notcve.org/view.php?id=CVE-2023-52735
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: 0CVE-2023-52733 – s390/decompressor: specify __decompress() buf len to avoid overflow
https://notcve.org/view.php?id=CVE-2023-52733
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: 0CVE-2023-52732 – ceph: blocklist the kclient when receiving corrupted snap trace
https://notcve.org/view.php?id=CVE-2023-52732
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: 7EXPL: 0CVE-2023-52730 – mmc: sdio: fix possible resource leaks in some error paths
https://notcve.org/view.php?id=CVE-2023-52730
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') •