CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38667 – riscv: prevent pt_regs corruption for secondary idle threads
https://notcve.org/view.php?id=CVE-2024-38667
In the Linux kernel, the following vulnerability has been resolved: riscv: prevent pt_regs corruption for secondary idle threads Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context. • https://git.kernel.org/stable/c/2875fe0561569f82d0e63658ccf0d11ce7da8922 https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44 https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80 https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af • CWE-787: Out-of-bounds Write •
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 •