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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38636 – f2fs: multidev: fix to recognize valid zero block address
https://notcve.org/view.php?id=CVE-2024-38636
In the Linux kernel, the following vulnerability has been resolved: f2fs: multidev: fix to recognize valid zero block address As reported by Yi Zhang in mailing list [1], kernel warning was catched during zbd/010 test as below: ./check zbd/010 zbd/010 (test gap zone support with F2FS) [failed] runtime ... 3.752s something found in dmesg: [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13 [ 4378.192349] null_blk: module loaded [ 4378.209860] null_blk: disk nullb0 created [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520] dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20 [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device ... (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg' WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Call Trace: <TASK> __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Shinichiro Kawasaki helps to analyse this issue and proposes a potential fixing patch in [2]. Quoted from reply of Shinichiro Kawasaki: "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a look in the commit, but it looks fine to me. So I thought the cause is not in the commit diff. I found the WARN is printed when the f2fs is set up with multiple devices, and read requests are mapped to the very first block of the second device in the direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached() modify map->m_pblk as the physical block address from each block device. • https://git.kernel.org/stable/c/1517c1a7a4456f080fabc4ac9853930e4b880d14 https://git.kernel.org/stable/c/1a9225fdd0ec95fcf32936bcea9ceef0cf1512dc https://git.kernel.org/stable/c/2b2611a42462c6c685d40b5f3aedcd8d21c27065 https://git.kernel.org/stable/c/e8b485e39b4d17afa9a2821fc778d5a67abfc03a https://git.kernel.org/stable/c/33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5 •