CVSS: 7.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47295 – net: sched: fix memory leak in tcindex_partial_destroy_work
https://notcve.org/view.php?id=CVE-2021-47295
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix memory leak in tcindex_partial_destroy_work Syzbot reported memory leak in tcindex_set_parms(). The problem was in non-freed perfect hash in tcindex_partial_destroy_work(). In tcindex_set_parms() new tcindex_data is allocated and some fields from old one are copied to new one, but not the perfect hash. Since tcindex_partial_destroy_work() is the destroy function for old tcindex_data, we need to free perfect hash to avoid memory leak. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: sched: corrige la pérdida de memoria en tcindex_partial_destroy_work Syzbot informó una pérdida de memoria en tcindex_set_parms(). El problema estaba en el hash perfecto no liberado en tcindex_partial_destroy_work(). • https://git.kernel.org/stable/c/331b72922c5f58d48fd5500acadc91777cc31970 https://git.kernel.org/stable/c/8d7924ce85bae64e7a67c366c7c50840f49f3a62 https://git.kernel.org/stable/c/8e9662fde6d63c78eb1350f6167f64c9d71a865b https://git.kernel.org/stable/c/cac71d27745f92ee13f0ecc668ffe151a4a9c9b1 https://git.kernel.org/stable/c/f5051bcece50140abd1a11a2d36dc3ec5484fc32 • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2021-47294 – netrom: Decrease sock refcount when sock timers expire
https://notcve.org/view.php?id=CVE-2021-47294
In the Linux kernel, the following vulnerability has been resolved: netrom: Decrease sock refcount when sock timers expire Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use sock timer API. It replaces mod_timer() by sk_reset_timer(), and del_timer() by sk_stop_timer(). Function sk_reset_timer() will increase the refcount of sock if it is called on an inactive timer, hence, in case the timer expires, we need to decrease the refcount ourselves in the handler, otherwise, the sock refcount will be unbalanced and the sock will never be freed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netrom: Disminuir el recuento de sock cuando caducan los temporizadores de sock. La confirmación 63346650c1a9 ("netrom: cambiar a API de temporizador de sock") cambió para usar la API de temporizador de sock. Reemplaza mod_timer() por sk_reset_timer() y del_timer() por sk_stop_timer(). • https://git.kernel.org/stable/c/ce29e8a259de767f7210d346ad2b031cb8ab2732 https://git.kernel.org/stable/c/baa9e32336bf6d0d74a7c3486d2a27feaf57cd5f https://git.kernel.org/stable/c/0adf571fa34b27bd0b97b408cc0f0dc54b72f0eb https://git.kernel.org/stable/c/2c6b572458a9127e8070df13fa7f115c29ab1d92 https://git.kernel.org/stable/c/63346650c1a94a92be61a57416ac88c0a47c4327 https://git.kernel.org/stable/c/f1d9a1f2ef6ff17293d21d5e6b80e04bea0cf508 https://git.kernel.org/stable/c/519e8a22a454b1f1baa3a151b184fe51bc18e178 https://git.kernel.org/stable/c/853262355518cd1247515b74e83fabf03 •
CVSS: 4.2EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47293 – net/sched: act_skbmod: Skip non-Ethernet packets
https://notcve.org/view.php?id=CVE-2021-47293
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: Skip non-Ethernet packets Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2 protocol, which is not always the case. As an example, for CAN devices: $ ip link add dev vcan0 type vcan $ ip link set up vcan0 $ tc qdisc add dev vcan0 root handle 1: htb $ tc filter add dev vcan0 parent 1: protocol ip prio 10 \ matchall action skbmod swap mac Doing the above silently corrupts all the packets. Do not perform skbmod actions for non-Ethernet packets. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_skbmod: omitir paquetes que no sean Ethernet. Actualmente, tcf_skbmod_act() asume que los paquetes usan Ethernet como protocolo L2, lo cual no siempre es el caso. • https://git.kernel.org/stable/c/86da71b57383d40993cb90baafb3735cffe5d800 https://git.kernel.org/stable/c/e4fdca366806f6bab374d1a95e626a10a3854b0c https://git.kernel.org/stable/c/a88414fb1117f2fe65fb88e45ba694e1d09d5024 https://git.kernel.org/stable/c/071729150be9e1d1b851b70efb6d91ee9269d57b https://git.kernel.org/stable/c/34f1e1f657fae2891b485a3b2b95fe4d2aef9f0d https://git.kernel.org/stable/c/727d6a8b7ef3d25080fad228b2c4a1d4da5999c6 https://access.redhat.com/security/cve/CVE-2021-47293 https://bugzilla.redhat.com/show_bug.cgi?id=2282504 • CWE-20: Improper Input Validation •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47289 – ACPI: fix NULL pointer dereference
https://notcve.org/view.php?id=CVE-2021-47289
In the Linux kernel, the following vulnerability has been resolved: ACPI: fix NULL pointer dereference Commit 71f642833284 ("ACPI: utils: Fix reference counting in for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer that was possibly NULL. That fails miserably, because that helper inline function is not set up to handle that case. Just make acpi_dev_put() silently accept a NULL pointer, rather than calling down to put_device() with an invalid offset off that NULL pointer. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ACPI: corrige la desreferencia del puntero NULL. La confirmación 71f642833284 ("ACPI: utils: corrige el recuento de referencias en for_each_acpi_dev_match()") comenzó a hacer "acpi_dev_put()" en un puntero que posiblemente era NULL. Eso falla estrepitosamente, porque esa función auxiliar en línea no está configurada para manejar ese caso. • https://git.kernel.org/stable/c/38f54217b423c0101d03a00feec6fb8ec608b12e https://git.kernel.org/stable/c/cae3fa3d8165761f3000f523b11cfa1cd35206bc https://git.kernel.org/stable/c/ccf23a0888077a25a0793a746c3941db2a7562e4 https://git.kernel.org/stable/c/fc68f42aa737dc15e7665a4101d4168aadb8e4c4 https://access.redhat.com/security/cve/CVE-2021-47289 https://bugzilla.redhat.com/show_bug.cgi?id=2282508 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47288 – media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
https://notcve.org/view.php?id=CVE-2021-47288
In the Linux kernel, the following vulnerability has been resolved: media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: ngene: corrige un error fuera de los límites en ngene_command_config_free_buf(). • https://git.kernel.org/stable/c/dae52d009fc950b5c209260d50fcc000f5becd3c https://git.kernel.org/stable/c/4487b968e5eacd02c493303dc2b61150bb7fe4b2 https://git.kernel.org/stable/c/c6ddeb63dd543b5474b0217c4e47538b7ffd7686 https://git.kernel.org/stable/c/e818f2ff648581a6c553ae2bebc5dcef9a8bb90c https://git.kernel.org/stable/c/ec731c6ef564ee6fc101fc5d73e3a3a953d09a00 https://git.kernel.org/stable/c/e617fa62f6cf859a7b042cdd6c73af905ff8fca3 https://git.kernel.org/stable/c/e991457afdcb5f4dbc5bc9d79eaf775be33e7092 https://git.kernel.org/stable/c/b9a178f189bb6d75293573e181928735f •