CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-37021 – fpga: manager: add owner module and take its refcount
https://notcve.org/view.php?id=CVE-2024-37021
In the Linux kernel, the following vulnerability has been resolved: fpga: manager: add owner module and take its refcount The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga manager. Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions. • https://git.kernel.org/stable/c/654ba4cc0f3ed7c0f08bfb39f66059d8c42943ee https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36479 – fpga: bridge: add owner module and take its refcount
https://notcve.org/view.php?id=CVE-2024-36479
In the Linux kernel, the following vulnerability has been resolved: fpga: bridge: add owner module and take its refcount The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge. Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions. • https://git.kernel.org/stable/c/21aeda950c5f84a8351b862816d832120b217a9b https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125 https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35247 – fpga: region: add owner module and take its refcount
https://notcve.org/view.php?id=CVE-2024-35247
In the Linux kernel, the following vulnerability has been resolved: fpga: region: add owner module and take its refcount The current implementation of the fpga region assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the region during programming if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_region struct and use it to take the module's refcount. Modify the functions for registering a region to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the region as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a region without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga region. • https://git.kernel.org/stable/c/0fa20cdfcc1f68847cdfc47824476301eedc8297 https://git.kernel.org/stable/c/26e6e25d742e29885cf44274fcf6b744366c4702 https://git.kernel.org/stable/c/9b4eee8572dcf82b2ed17d9a328c7fb87df2f0e8 https://git.kernel.org/stable/c/75a001914a8d2ccdcbe4b8cc7e94ac71d0e66093 https://git.kernel.org/stable/c/4d7d12b643c00e7eea51b49a60a2ead182633ec8 https://git.kernel.org/stable/c/2279c09c36165ccded4d506d11a7714e13b56019 https://git.kernel.org/stable/c/b7c0e1ecee403a43abc89eb3e75672b01ff2ece9 •
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: 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 •