Page 303 of 3382 results (0.010 seconds)

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

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: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions While running the self-tests on a KASAN enabled kernel, I observed a slab-out-of-bounds splat very similar to the one reported in commit 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions"). We additionally need to take care of fib6_metrics initialization failure when the caller provides an nh. The fix is similar, explicitly free the route instead of calling fib6_info_release on a half-initialized object. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: corrige otra slab fuera de los límites en fib6_nh_flush_exceptions. Mientras ejecutaba las autopruebas en un kernel habilitado para KASAN, observé una slab fuera de los límites muy similar al informado en la confirmación 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions"). Además, debemos ocuparnos del error de inicialización de fib6_metrics cuando la persona que llama proporciona un nh. La solución es similar: libera explícitamente la ruta en lugar de llamar a fib6_info_release en un objeto medio inicializado. • https://git.kernel.org/stable/c/f88d8ea67fbdbac7a64bfa6ed9a2ba27bb822f74 https://git.kernel.org/stable/c/830251361425c5be044db4d826aaf304ea3d14c6 https://git.kernel.org/stable/c/ce8fafb68051fba52546f8bbe8621f7641683680 https://git.kernel.org/stable/c/115784bcccf135c3a3548098153413d76f16aae0 https://git.kernel.org/stable/c/8fb4792f091e608a0a1d353dfdf07ef55a719db5 •

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

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: 0

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 •

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

In the Linux kernel, the following vulnerability has been resolved: driver core: auxiliary bus: Fix memory leak when driver_register() fail If driver_register() returns with error we need to free the memory allocated for auxdrv->driver.name before returning from __auxiliary_driver_register() En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: bus auxiliar: corrige la pérdida de memoria cuando falla driver_register(). Si driver_register() regresa con error, necesitamos liberar la memoria asignada para auxdrv->driver.name antes de regresar de __auxiliary_driver_register() • https://git.kernel.org/stable/c/7de3697e9cbd4bd3d62bafa249d57990e1b8f294 https://git.kernel.org/stable/c/ce5b3de58fc21303722df46551f7eb9a91afb409 https://git.kernel.org/stable/c/4afa0c22eed33cfe0c590742387f0d16f32412f3 https://access.redhat.com/security/cve/CVE-2021-47287 https://bugzilla.redhat.com/show_bug.cgi?id=2282511 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •