CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-34027 – f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
https://notcve.org/view.php?id=CVE-2024-34027
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. • https://git.kernel.org/stable/c/c75488fb4d82b697f381f855bf5b16779df440aa https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182 https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4 https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39292 – um: Add winch to winch_handlers before registering winch IRQ
https://notcve.org/view.php?id=CVE-2024-39292
In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: Agregar cabrestante a winch_handlers antes de registrar la IRQ del cabrestante Registrar una IRQ del cabrestante es picante, puede ocurrir una interrupción antes de que el cabrestante se agregue a la lista de winch_handlers. Si eso sucede, Register_winch_irq() agrega a esa lista un cabrestante que está programado para ser liberado (o que ya ha sido) liberado, causando pánico más adelante en winch_cleanup(). Evite la ejecución agregando el cabrestante a la lista winch_handlers antes de registrar la IRQ y retrocediendo si um_request_irq() falla. • https://git.kernel.org/stable/c/42a359e31a0e438b5b978a8f0fecdbd3c86bb033 https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33 https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0 https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14 https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2 https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4 https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0 https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a • CWE-415: Double Free •
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 •