CVSS: 5.3EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47515 – seg6: fix the iif in the IPv6 socket control block
https://notcve.org/view.php?id=CVE-2021-47515
In the Linux kernel, the following vulnerability has been resolved: seg6: fix the iif in the IPv6 socket control block When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif; If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29). Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero). As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied. To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: seg6: corrige el iif en el bloque de control del socket IPv6 Cuando se recibe un paquete IPv4, ip_rcv_core(...) establece el índice de la interfaz de recepción en el bloque de control del socket IPv4 (v5 .16-rc4, net/ipv4/ip_input.c línea 510): IPCB(skb)->iif = skb->skb_iif; Si ese paquete IPv4 debe encapsularse en un encabezado IPv6+SRH externo, seg6_do_srh_encap(...) realiza la encapsulación requerida. En este caso, la función seg6_do_srh_encap borra el bloque de control del socket IPv6 (v5.16-rc4 net/ipv6/seg6_iptunnel.c línea 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); El memset(...) se introdujo en El commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) en la encapsulación SRH ip4ip6") hace mucho tiempo (29 de enero de 2019). Dado que el bloque de control del socket IPv6 y el bloque de control del socket IPv4 comparten la misma área de memoria (skb->cb), la información del índice de la interfaz de recepción se pierde (IP6CB(skb)->iif se establece en cero). Como efecto secundario, esa condición desencadena una desreferencia del puntero NULL si se aplica el commit 0857d6f8c759 ("ipv6: al reenviar estadísticas de recuento de rx en el netdev original"). • https://git.kernel.org/stable/c/c630ec8bdadae9d557b1ceb9d6c06e149108a0d4 https://git.kernel.org/stable/c/2f704348c93ff8119e642dae6a72327f90b82810 https://git.kernel.org/stable/c/ef489749aae508e6f17886775c075f12ff919fb1 https://git.kernel.org/stable/c/b71b7e0280f47b4ac633fbfd153423814ea87810 https://git.kernel.org/stable/c/b16d412e5f79734033df04e97d7ea2f50a8e9fe3 https://git.kernel.org/stable/c/6431e71093f3da586a00c6d931481ffb0dc2db0e https://git.kernel.org/stable/c/ef8804e47c0a44ae106ead1740408af5ea6c6ee9 https://git.kernel.org/stable/c/666521b3852d2b2f52d570f9122b1e4b5 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47514 – devlink: fix netns refcount leak in devlink_nl_cmd_reload()
https://notcve.org/view.php?id=CVE-2021-47514
In the Linux kernel, the following vulnerability has been resolved: devlink: fix netns refcount leak in devlink_nl_cmd_reload() While preparing my patch series adding netns refcount tracking, I spotted bugs in devlink_nl_cmd_reload() Some error paths forgot to release a refcount on a netns. To fix this, we can reduce the scope of get_net()/put_net() section around the call to devlink_reload(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: devlink: corrige la fuga de refcount de netns en devlink_nl_cmd_reload() Mientras preparaba mi serie de parches agregando el seguimiento de refcount de netns, detecté errores en devlink_nl_cmd_reload() Algunas rutas de error olvidaron publicar un refcount en netns. Para solucionar este problema, podemos reducir el alcance de la sección get_net()/put_net() alrededor de la llamada a devlink_reload(). • https://git.kernel.org/stable/c/ccdf07219da6bd1f43c6ddcde4c0e36993c7365a https://git.kernel.org/stable/c/4b7e90672af8e0c78205db006f1b0a20ebd07f5f https://git.kernel.org/stable/c/fe30b70ca84da9c4aca85c03ad86e7a9b89c5ded https://git.kernel.org/stable/c/4dbb0dad8e63fcd0b5a117c2861d2abe7ff5f186 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47513 – net: dsa: felix: Fix memory leak in felix_setup_mmio_filtering
https://notcve.org/view.php?id=CVE-2021-47513
In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: Fix memory leak in felix_setup_mmio_filtering Avoid a memory leak if there is not a CPU port defined. Addresses-Coverity-ID: 1492897 ("Resource leak") Addresses-Coverity-ID: 1492899 ("Resource leak") En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:dsa:felix: Reparar pérdida de memoria en felix_setup_mmio_filtering Evitar una pérdida de memoria si no hay un puerto de CPU definido. Direcciones-Coverity-ID: 1492897 ("Fuga de recursos") Direcciones-Coverity-ID: 1492899 ("Fuga de recursos") • https://git.kernel.org/stable/c/8d5f7954b7c8de54902a8beda141064a7e2e6ee0 https://git.kernel.org/stable/c/6b55eadb0b1da827f198364c426ace72c16c49b0 https://git.kernel.org/stable/c/973a0373e88cc19129bd6ef0ec193040535397d9 https://git.kernel.org/stable/c/e8b1d7698038e76363859fb47ae0a262080646f5 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47512 – net/sched: fq_pie: prevent dismantle issue
https://notcve.org/view.php?id=CVE-2021-47512
In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: prevent dismantle issue For some reason, fq_pie_destroy() did not copy working code from pie_destroy() and other qdiscs, thus causing elusive bug. Before calling del_timer_sync(&q->adapt_timer), we need to ensure timer will not rearm itself. rcu: INFO: rcu_preempt self-detected stall on CPU rcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579 (t=10501 jiffies g=13085 q=3989) NMI backtrace for cpu 0 CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343 print_cpu_stall kernel/rcu/tree_stall.h:627 [inline] check_cpu_stall kernel/rcu/tree_stall.h:711 [inline] rcu_pending kernel/rcu/tree.c:3878 [inline] rcu_sched_clock_irq.cold+0x9d/0x746 kernel/rcu/tree.c:2597 update_process_times+0x16d/0x200 kernel/time/timer.c:1785 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226 tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428 __run_hrtimer kernel/time/hrtimer.c:1685 [inline] __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749 hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline] __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103 sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638 RIP: 0010:write_comp_data kernel/kcov.c:221 [inline] RIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1d/0x80 kernel/kcov.c:273 Code: 54 c8 20 48 89 10 c3 66 0f 1f 44 00 00 53 41 89 fb 41 89 f1 bf 03 00 00 00 65 48 8b 0c 25 40 70 02 00 48 89 ce 4c 8b 54 24 08 <e8> 4e f7 ff ff 84 c0 74 51 48 8b 81 88 15 00 00 44 8b 81 84 15 00 RSP: 0018:ffffc90000d27b28 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888064bf1bf0 RCX: ffff888011928000 RDX: ffff888011928000 RSI: ffff888011928000 RDI: 0000000000000003 RBP: ffff888064bf1c28 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff875d8295 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880783dd300 R14: 0000000000000000 R15: 0000000000000000 pie_calculate_probability+0x405/0x7c0 net/sched/sch_pie.c:418 fq_pie_timer+0x170/0x2a0 net/sched/sch_fq_pie.c:383 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 expire_timers kernel/time/timer.c:1466 [inline] __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734 __run_timers kernel/time/timer.c:1715 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: fq_pie: previene el problema de desmantelamiento Por alguna razón, fq_pie_destroy() no copió el código de trabajo de pie_destroy() y otras qdiscs, causando así un error difícil de alcanzar. Antes de llamar a del_timer_sync(&q->adapt_timer), debemos asegurarnos de que el temporizador no se rearme solo. rcu: INFO: rcu_preempt se bloqueó automáticamente en la CPU rcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579 (t=10501 jiffies g=13085 q=3989) NMI backtrace for cpu 0 CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343 print_cpu_stall kernel/rcu/tree_stall.h:627 [inline] check_cpu_stall kernel/rcu/tree_stall.h:711 [inline] rcu_pending kernel/rcu/tree.c:3878 [inline] rcu_sched_clock_irq.cold+0x9d/0x746 kernel/rcu/tree.c:2597 update_process_times+0x16d/0x200 kernel/time/timer.c:1785 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226 tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428 __run_hrtimer kernel/time/hrtimer.c:1685 [inline] __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749 hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline] __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103 sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638 RIP: 0010:write_comp_data kernel/kcov.c:221 [inline] RIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1d/0x80 kernel/kcov.c:273 Code: 54 c8 20 48 89 10 c3 66 0f 1f 44 00 00 53 41 89 fb 41 89 f1 bf 03 00 00 00 65 48 8b 0c 25 40 70 02 00 48 89 ce 4c 8b 54 24 08 4e f7 ff ff 84 c0 74 51 48 8b 81 88 15 00 00 44 8b 81 84 15 00 RSP: 0018:ffffc90000d27b28 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888064bf1bf0 RCX: ffff888011928000 RDX: ffff888011928000 RSI: ffff888011928000 RDI: 0000000000000003 RBP: ffff888064bf1c28 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff875d8295 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880783dd300 R14: 0000000000000000 R15: 0000000000000000 pie_calculate_probability+0x405/0x7c0 net/sched/sch_pie.c:418 fq_pie_timer+0x170/0x2a0 net/sched/sch_fq_pie.c:383 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 expire_timers kernel/time/timer.c:1466 [inline] __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734 __run_timers kernel/time/timer.c:1715 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 • https://git.kernel.org/stable/c/ec97ecf1ebe485a17cd8395a5f35e6b80b57665a https://git.kernel.org/stable/c/2a51edaf5cc563574878b93d7ef3d5955dda7030 https://git.kernel.org/stable/c/d86216dfda7c98375f809e26a30bfdaaba21d46e https://git.kernel.org/stable/c/61c2402665f1e10c5742033fce18392e369931d7 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47511 – ALSA: pcm: oss: Fix negative period/buffer sizes
https://notcve.org/view.php?id=CVE-2021-47511
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix negative period/buffer sizes The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: oss: corrige tamaños de período/búfer negativos El cálculo del tamaño del período en la capa OSS puede recibir un valor negativo como error, pero el código allí asume solo los valores positivos y manejarlos con size_t. Debido a esto, es posible que se pase un valor demasiado grande a las capas inferiores. Este parche cambia el código para manejar con ssize_t y agrega las comprobaciones de errores adecuadas. • https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2 https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049 https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243 https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823 https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c •