CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-39277 – dma-mapping: benchmark: handle NUMA_NO_NODE correctly
https://notcve.org/view.php?id=CVE-2024-39277
In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: handle NUMA_NO_NODE correctly cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan.c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Use cpumask_of_node() in place when binding a kernel thread to a cpuset of a particular node. Note that the provided node id is checked inside map_benchmark_ioctl(). It's just a NUMA_NO_NODE case which is not handled properly later. Found by Linux Verification Center (linuxtesting.org). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-mapping: benchmark: maneja NUMA_NO_NODE correctamente. Se puede llamar a cpumask_of_node() para NUMA_NO_NODE dentro de do_map_benchmark(), lo que genera el siguiente informe de sanitización: UBSAN: array-index-out-of- Los límites en ./arch/x86/include/asm/topology.h:72:28 el índice -1 están fuera del rango para el tipo 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma No contaminado 6.9. 0-rc6 #29 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan. c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [en línea] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) full_proxy_unlocked_ioctl (fs /debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) Entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Utilice cpumask_of_node( ) en su lugar al vincular un subproceso del kernel a un cpuset de un nodo en particular. • https://git.kernel.org/stable/c/65789daa8087e125927230ccb7e1eab13999b0cf https://git.kernel.org/stable/c/b41b0018e8ca06e985e87220a618ec633988fd13 https://git.kernel.org/stable/c/8e1ba9df9a35e8dc64f657a64e523c79ba01e464 https://git.kernel.org/stable/c/5a91116b003175302f2e6ad94b76fb9b5a141a41 https://git.kernel.org/stable/c/50ee21bfc005e69f183d6b4b454e33f0c2571e1f https://git.kernel.org/stable/c/e64746e74f717961250a155e14c156616fcd981f • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38780 – dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
https://notcve.org/view.php?id=CVE-2024-38780
In the Linux kernel, the following vulnerability has been resolved: dma-buf/sw-sync: don't enable IRQ from sync_print_obj() Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf/sw-sync: no habilitar IRQ desde sync_print_obj() Desde el commit a6aa8fca4d79 ("dma-buf/sw-sync: reducir irqsave/irqrestore desde el contexto conocido" ) por error reemplazó spin_unlock_irqrestore() con spin_unlock_irq() tanto para sync_debugfs_show() como para sync_print_obj() a pesar de que sync_print_obj() se llama desde sync_debugfs_show(), lockdep se queja de una advertencia de estado de bloqueo inconsistente. Utilice spin_{lock,unlock}() simple para sync_print_obj(), ya que sync_debugfs_show() ya está usando spin_{lock,unlock}_irq(). • https://git.kernel.org/stable/c/a6aa8fca4d792c72947e341d7842d2f700534335 https://git.kernel.org/stable/c/f14ad42b8743897d140808467ed4ae3ce93bd0a5 https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8 https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878 https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc54396 • CWE-667: Improper Locking •
CVSS: 4.7EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38662 – bpf: Allow delete from sockmap/sockhash only if update is allowed
https://notcve.org/view.php?id=CVE-2024-38662
In the Linux kernel, the following vulnerability has been resolved: bpf: Allow delete from sockmap/sockhash only if update is allowed We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash. We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map. From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: permitir la eliminación de sockmap/sockhash solo si se permite la actualización. Hemos visto una afluencia de informes de syzkaller donde un programa BPF adjunto a un punto de seguimiento desencadena una violación de la regla de bloqueo al realizar un map_delete en un mapa de calcetines/sockhash. No pretendemos apoyar este escenario de uso artificial. • https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75 https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5 https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86 https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48 https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058 https://git.kernel.org/stable/c/913c30f827e17d8cda1da6eeb990f350d36cb69b https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f2 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38659 – enic: Validate length of nl attributes in enic_set_vf_port
https://notcve.org/view.php?id=CVE-2024-38659
In the Linux kernel, the following vulnerability has been resolved: enic: Validate length of nl attributes in enic_set_vf_port enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enic_set_vf_port expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enic_set_vf_port. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: enic: Validar la longitud de los atributos nl en enic_set_vf_port enic_set_vf_port supone que el atributo nl IFLA_PORT_PROFILE tiene una longitud PORT_PROFILE_MAX y que los atributos nl IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID tienen una longitud PORT_UUID_MAX. • https://git.kernel.org/stable/c/f8bd909183acffad68780b10c1cdf36161cfd5d1 https://git.kernel.org/stable/c/2b649d7e0cb42a660f0260ef25fd55fdc9c6c600 https://git.kernel.org/stable/c/ca63fb7af9d3e531aa25f7ae187bfc6c7166ec2d https://git.kernel.org/stable/c/3c0d36972edbe56fcf98899622d9b90ac9965227 https://git.kernel.org/stable/c/25571a12fbc8a1283bd8380d461267956fd426f7 https://git.kernel.org/stable/c/7077c22f84f41974a711604a42fd0e0684232ee5 https://git.kernel.org/stable/c/f6638e955ca00c489894789492776842e102af9c https://git.kernel.org/stable/c/aee1955a1509a921c05c70dad5d6fc856 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38637 – greybus: lights: check return of get_channel_from_mode
https://notcve.org/view.php?id=CVE-2024-38637
In the Linux kernel, the following vulnerability has been resolved: greybus: lights: check return of get_channel_from_mode If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru En el kernel de Linux, se resolvió la siguiente vulnerabilidad: greybus: luces: verificar el retorno de get_channel_from_mode Si no se encuentra el canal para el nodo dado, devolvemos nulo de get_channel_from_mode. Asegúrese de validar el puntero de retorno antes de usarlo en dos de los lugares que faltan. Esto se informó originalmente en [0]: Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru • https://git.kernel.org/stable/c/2870b52bae4c81823ffcb3ed2b0626fb39d64f48 https://git.kernel.org/stable/c/8f4a76d477f0cc3c54d512f07f6f88c8e1c1e07b https://git.kernel.org/stable/c/e2c64246e5dc8c0d35ec41770b85e2b4cafdff21 https://git.kernel.org/stable/c/eac10cf3a97ffd4b4deb0a29f57c118225a42850 https://git.kernel.org/stable/c/330f6bcdcef03f70f81db5f2ed6747af656a09f2 https://git.kernel.org/stable/c/9b41a9b9c8be8c552f10633453fdb509e83b66f8 https://git.kernel.org/stable/c/518e2c46b5dbce40b1aa0100001d03c3ceaa7d38 https://git.kernel.org/stable/c/895cdd9aa9546523df839f9cc1488a0ec •