CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38542 – RDMA/mana_ib: boundary check before installing cq callbacks
https://notcve.org/view.php?id=CVE-2024-38542
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana_ib: boundary check before installing cq callbacks Add a boundary check inside mana_ib_install_cq_cb to prevent index overflow. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mana_ib: verificación de los límites antes de instalar devoluciones de llamadas de cq Agregue una verificación de los límites dentro de mana_ib_install_cq_cb para evitar el desbordamiento del índice. • https://git.kernel.org/stable/c/cf9cc859d6ff37ce52c09dfbb169b9ee25595a3f https://git.kernel.org/stable/c/2a31c5a7e0d87959a03e846523013c75f4395a91 https://git.kernel.org/stable/c/f12afddfb142587d786df9e3cc4862190d3e2ec8 https://git.kernel.org/stable/c/168f6fbde0eabd71d1f4133df7d001a950b96977 https://git.kernel.org/stable/c/f79edef79b6a2161f4124112f9b0c46891bb0b74 •
CVSS: 9.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38541 – of: module: add buffer overflow check in of_modalias()
https://notcve.org/view.php?id=CVE-2024-38541
In the Linux kernel, the following vulnerability has been resolved: of: module: add buffer overflow check in of_modalias() In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: of: módulo: agregar control de desbordamiento del búfer of_modalias() En of_modalias(), si el búfer es demasiado pequeño incluso para la primera llamada a snprintf(), el parámetro len se vuelve negativo y el parámetro str (si no es NULL inicialmente) apuntará más allá del final del búfer. Agregue la verificación de desbordamiento del búfer después de la primera llamada a snprintf() y corrija dicha verificación después de la llamada strlen() (teniendo en cuenta el carácter NUL de terminación). A buffer overflow flaw was found in of_modalias() in the Linux kernel, occurring after the first snprintf() call. • https://git.kernel.org/stable/c/bc575064d688c8933a6ca51429bea9bc63628d3b https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6 https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252 https://access.redhat.com/security/cve/CVE-2024-38541 https://bugzilla.redhat.com/show_bug.cgi?id=2293458 • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38540 – bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
https://notcve.org/view.php?id=CVE-2024-38540
In the Linux kernel, the following vulnerability has been resolved: bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0. In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called. roundup_pow_of_two is documented as undefined for 0. Fix it in the one caller that had this combination. The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re] ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? • https://git.kernel.org/stable/c/0c4dcd602817502bb3dced7a834a13ef717d65a4 https://git.kernel.org/stable/c/84d2f29152184f0d72ed7c9648c4ee6927df4e59 https://git.kernel.org/stable/c/a658f011d89dd20cf2c7cb4760ffd79201700b98 https://git.kernel.org/stable/c/627493443f3a8458cb55cdae1da254a7001123bc https://git.kernel.org/stable/c/8b799c00cea6fcfe5b501bbaeb228c8821acb753 https://git.kernel.org/stable/c/78cfd17142ef70599d6409cbd709d94b3da58659 https://access.redhat.com/security/cve/CVE-2024-38540 https://bugzilla.redhat.com/show_bug.cgi?id=2293459 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38539 – RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw
https://notcve.org/view.php?id=CVE-2024-38539
In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw When running blktests nvme/rdma, the following kmemleak issue will appear. kmemleak: Kernel memory leak detector initialized (mempool available:36041) kmemleak: Automatic memory scanning thread started kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff88855da53400 (size 192): comm "rdma", pid 10630, jiffies 4296575922 hex dump (first 32 bytes): 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7............... 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.].... backtrace (crc 47f66721): [<ffffffff911251bd>] kmalloc_trace+0x30d/0x3b0 [<ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core] [<ffffffffc2642206>] add_modify_gid+0x166/0x930 [ib_core] [<ffffffffc2643468>] ib_cache_update.part.0+0x6d8/0x910 [ib_core] [<ffffffffc2644e1a>] ib_cache_setup_one+0x24a/0x350 [ib_core] [<ffffffffc263949e>] ib_register_device+0x9e/0x3a0 [ib_core] [<ffffffffc2a3d389>] 0xffffffffc2a3d389 [<ffffffffc2688cd8>] nldev_newlink+0x2b8/0x520 [ib_core] [<ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core] [<ffffffffc264648c>] rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core] [<ffffffff9270e7b5>] netlink_unicast+0x445/0x710 [<ffffffff9270f1f1>] netlink_sendmsg+0x761/0xc40 [<ffffffff9249db29>] __sys_sendto+0x3a9/0x420 [<ffffffff9249dc8c>] __x64_sys_sendto+0xdc/0x1b0 [<ffffffff92db0ad3>] do_syscall_64+0x93/0x180 [<ffffffff92e00126>] entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause: rdma_put_gid_attr is not called when sgid_attr is set to ERR_PTR(-ENODEV). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/cma: corrija kmemleak en rdma_core observado durante el uso de blktests nvme/rdma siw Al ejecutar blktests nvme/rdma, aparecerá el siguiente problema de kmemleak. kmemleak: detector de pérdida de memoria del kernel inicializado (mempool disponible: 36041) kmemleak: hilo de escaneo automático de memoria iniciado kmemleak: 2 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) kmemleak: 8 nuevas pérdidas de memoria sospechosas (ver /sys/ kernel/debug/kmemleak) kmemleak: 17 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) kmemleak: 4 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmemleak) objeto sin referencia 0xffff88855da53400 (tamaño 192): comm "rdma", pid 10630, sjiffies 4296575922 volcado hexadecimal (primeros 32 bytes): 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7................. 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.].... backtrace (crc 47f66721): [] kmalloc_trace+0x30d/0x3b0 [< ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core] [] add_modify_gid+0x166/0x930 [ib_core] [] ib_cache_update.part.0+0x6d8/0x910 [ib_core] [] ib_cache_setup_one+0x24a/ 0x350 [ib_core] [] ib_register_device+0x9e/0x3a0 [ib_core] [] 0xffffffffc2a3d389 [] nldev_newlink+0x2b8/0x520 [ib_core] ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core] [ ] rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core] [] netlink_unicast+0x445/0x710 [] 0 [] __sys_sendto+0x3a9/0x420 [] __x64_sys_sendto+0xdc/0x1b0 [] do_syscall_64+0x93/0x180 [] Entry_SYSCALL_64_after_hwframe+0x71/0x79 La causa raíz: _gid_attr no se llama cuando sgid_attr está configurado en ERR_PTR(-ENODEV). • https://git.kernel.org/stable/c/f8ef1be816bf9a0c406c696368c2264a9597a994 https://git.kernel.org/stable/c/3eb127dc408bf7959a4920d04d16ce10e863686a https://git.kernel.org/stable/c/6564fc1818404254d1c9f7d75b403b4941516d26 https://git.kernel.org/stable/c/b3a7fb93afd888793ef226e9665fbda98a95c48e https://git.kernel.org/stable/c/9c0731832d3b7420cbadba6a7f334363bc8dfb15 •
CVSS: 7.1EPSS: 0%CPEs: 9EXPL: 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/3e01fc3c66e65d9afe98f1489047a1b2dd8741ca https://git.kernel.org/stable/c/b2b7c43cd32080221bb233741bd6011983fe7c11 https://git.kernel.org/stable/c/82090f94c723dab724b1c32db406091d40448a17 https://git.kernel.org/stable/c/c964429ef53f42098a6545a5dabeb1441c1e821d https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2 https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5 https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •