CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38538 – net: bridge: xmit: make sure we have at least eth header len bytes
https://notcve.org/view.php?id=CVE-2024-38538
In the Linux kernel, the following vulnerability has been resolved: net: bridge: xmit: make sure we have at least eth header len bytes syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: xmit: asegúrese de tener al menos el encabezado eth len bytes syzbot desencadenó un error de valor uninit[1] en la ruta xmit del dispositivo puente al enviar un mensaje corto (menos de ETH_HLEN bytes) skb. Para solucionarlo, compruebe si realmente podemos retirar esa cantidad en lugar de suponerla. Probado con dropwatch: soltar en: br_dev_xmit+0xb93/0x12d0 [puente] (0xffffffffc06739b3) origen: marca de tiempo del software: lunes 13 de mayo 11:31:53 2024 778214037 protocolo nsec: 0x88a8 longitud: 2 longitud original: 2 motivo de caída: PKT_TOO_SMALL [1 ] ERROR: KMSAN: valor uninit en br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [en línea] netdev_start_xmit include/linux/netdevice.h:4917 [en línea] xmit_one net/core/dev.c:3531 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev .c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] __bpf_tx_skb net/core/filter.c:2136 [en línea] __bpf_redirect_common net/core/filter.c:2180 [en línea] __bpf_redirect+0x14a6/0x1620 net/ Core/Filter.C: 2187 ____BPF_CLONE_REDIRECT NET/CORE/FILTRO.C: 2460 [Inline] BPF_CLONE_REDIRECT+0x328/0x470 NET/Core/Filter.c: 2432 ___ BPF_PROG_RUN+0X13FE/0XE0F0 KERNEL/BPF/BPF/CORE. 0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [en línea] __bpf_prog_run include/linux/filter.h:657 [en línea] bpf_prog_run include/linux/filter.h:664 [en línea ] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 pf+0x6aa/0xd90 núcleo/ bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5765 [en línea] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 ys_call+0x96b /0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+ 0x77/0x7f • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2 https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5 https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36e2488f2 https://git.kernel.org/stable/c/5b5d669f569807c7ab07546e73c0741845a2547a https://git.kernel.org/stable/c/8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc https://access.redhat.com/security/cve/CVE-2024-38538 https://bugzilla.redhat.com/show_bug.cgi?id=2293461 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 6.6EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36979 – net: bridge: mst: fix vlan use-after-free
https://notcve.org/view.php?id=CVE-2024-36979
In the Linux kernel, the following vulnerability has been resolved: net: bridge: mst: fix vlan use-after-free syzbot reported a suspicious rcu usage[1] in bridge's mst code. While fixing it I noticed that nothing prevents a vlan to be freed while walking the list from the same path (br forward delay timer). Fix the rcu usage and also make sure we are not accessing freed memory by making br_mst_vlan_set_state use rcu read lock. [1] WARNING: suspicious RCU usage 6.9.0-rc6-syzkaller #0 Not tainted ----------------------------- net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage! ... stack backtrace: CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nbp_vlan_group net/bridge/br_private.h:1599 [inline] br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105 br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47 br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88 call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429 run_timer_base kernel/time/timer.c:2438 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448 __do_softirq+0x2c6/0x980 kernel/softirq.c:554 invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633 irq_exit_rcu+0x9/0x30 kernel/softirq.c:645 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758 Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25 RSP: 0018:ffffc90013657100 EFLAGS: 00000206 RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001 RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60 RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0 R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28 R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: mst: fix vlan use-after-free syzbot informó un uso sospechoso de rcu[1] en el código mst del puente. Mientras lo solucionaba, noté que nada impide que se libere una VLAN mientras se recorre la lista desde el mismo camino (br temporizador de retardo de avance). • https://git.kernel.org/stable/c/ec7328b59176227216c461601c6bd0e922232a9b https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59 https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4 https://git.kernel.org/stable/c/3a7c1661ae1383364cd6092d851f5e5da64d476b https://access.redhat.com/security/cve/CVE-2024-36979 https://bugzilla.redhat.com/show_bug.cgi?id=2293276 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36978 – net: sched: sch_multiq: fix possible OOB write in multiq_tune()
https://notcve.org/view.php?id=CVE-2024-36978
In the Linux kernel, the following vulnerability has been resolved: net: sched: sch_multiq: fix possible OOB write in multiq_tune() q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: sch_multiq: corrige posible escritura OOB en multiq_tune() q->bands se asignarán a qopt->bands para ejecutar la lógica de código posterior después de kmalloc. Por lo tanto, las antiguas q->bands no deberían usarse en kmalloc. De lo contrario, se producirá una escritura fuera de los límites. • https://git.kernel.org/stable/c/c2999f7fb05b87da4060e38150c70fa46794d82b https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3 https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882 https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129 https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36975 – KEYS: trusted: Do not use WARN when encode fails
https://notcve.org/view.php?id=CVE-2024-36975
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Do not use WARN when encode fails When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LLAVES: confiable: no usar WARN cuando falla la codificación Cuando falla asn1_encode_sequence(), WARN no es la solución correcta. 1. asn1_encode_sequence() no es una función interna (ubicada en lib/asn1_encode.c). 2. Se conoce la ubicación, lo que hace que el seguimiento de la pila sea inútil. 3. • https://git.kernel.org/stable/c/f2219745250f388edacabe6cca73654131c67d0a https://git.kernel.org/stable/c/96f650995c70237b061b497c66755e32908f8972 https://git.kernel.org/stable/c/681935009fec3fc22af97ee312d4a24ccf3cf087 https://git.kernel.org/stable/c/1c652e1e10676f942149052d9329b8bf2703529a https://git.kernel.org/stable/c/d32c6e09f7c4bec3ebc4941323f0aa6366bc1487 https://git.kernel.org/stable/c/ff91cc12faf798f573dab2abc976c1d5b1862fea https://git.kernel.org/stable/c/050bf3c793a07f96bd1e2fd62e1447f731ed733b •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36974 – net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
https://notcve.org/view.php?id=CVE-2024-36974
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided, taprio_parse_mqprio_opt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called. First call (with valid attributes) sets dev->num_tc to a non zero value. Second call (with arbitrary mqprio attributes) returns early from taprio_parse_mqprio_opt() and bad things can happen. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: validar siempre TCA_TAPRIO_ATTR_PRIOMAP Si se ha proporcionado un atributo TCA_TAPRIO_ATTR_PRIOMAP, taprio_parse_mqprio_opt() debe validarlo, o el espacio de usuario puede inyectar datos arbitrarios al kernel, la segunda vez taprio_change () se llama. La primera llamada (con atributos válidos) establece dev->num_tc en un valor distinto de cero. La segunda llamada (con atributos mqprio arbitrarios) regresa temprano desde taprio_parse_mqprio_opt() y pueden suceder cosas malas. • https://git.kernel.org/stable/c/a3d43c0d56f1b94e74963a2fbadfb70126d92213 https://git.kernel.org/stable/c/c6041e7124464ce7e896ee3f912897ce88a0c4ec https://git.kernel.org/stable/c/6db4af09987cc5d5f0136bd46148b0e0460dae5b https://git.kernel.org/stable/c/d3dde4c217f0c31ab0621912e682b57e677dd923 https://git.kernel.org/stable/c/0bf6cc96612bd396048f57d63f1ad454a846e39c https://git.kernel.org/stable/c/724050ae4b76e4fae05a923cb54101d792cf4404 https://git.kernel.org/stable/c/c37a27a35eadb59286c9092c49c241270c802ae2 https://git.kernel.org/stable/c/f921a58ae20852d188f70842431ce6519 •