CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48772 – media: lgdt3306a: Add a check against null-pointer-def
https://notcve.org/view.php?id=CVE-2022-48772
In the Linux kernel, the following vulnerability has been resolved: media: lgdt3306a: Add a check against null-pointer-def The driver should check whether the client provides the platform_data. The following log reveals it: [ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90 • https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0 https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4 https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676 https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87 https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115 https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d •
CVSS: -EPSS: 0%CPEs: 4EXPL: 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/304f8032d601d4f9322ca841cd0b573bd1beb158 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: 4EXPL: 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/18dc8366abb6cadcb77668b1a16434654e355d49 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: 4.7EPSS: 0%CPEs: 3EXPL: 0CVE-2024-34030 – PCI: of_property: Return error for int_map allocation failure
https://notcve.org/view.php?id=CVE-2024-34030
In the Linux kernel, the following vulnerability has been resolved: PCI: of_property: Return error for int_map allocation failure Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a NULL pointer dereference in this case. [bhelgaas: commit log] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: of_property: error de devolución por falla de asignación de int_map Devuelve -ENOMEM de of_pci_prop_intr_map() si kcalloc() no logra evitar una desreferencia de puntero NULL en este caso. [bhelgaas: registro de confirmación] • https://git.kernel.org/stable/c/407d1a51921e9f28c1bcec647c2205925bd1fdab https://git.kernel.org/stable/c/b5f31d1470c4fdfae368feeb389768ba8d24fb34 https://git.kernel.org/stable/c/598e4a37a2f8da9144ba1fab04320c32169b6d0d https://git.kernel.org/stable/c/e6f7d27df5d208b50cae817a91d128fb434bb12c • CWE-476: NULL Pointer Dereference •