Page 178 of 3643 results (0.027 seconds)

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

24 Jun 2024 — 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 ... • https://git.kernel.org/stable/c/654ba4cc0f3ed7c0f08bfb39f66059d8c42943ee •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

24 Jun 2024 — 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 ... • https://git.kernel.org/stable/c/21aeda950c5f84a8351b862816d832120b217a9b •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

24 Jun 2024 — 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 modul... • https://git.kernel.org/stable/c/0fa20cdfcc1f68847cdfc47824476301eedc8297 •

CVSS: 7.0EPSS: 0%CPEs: 3EXPL: 0

24 Jun 2024 — 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... • https://git.kernel.org/stable/c/407d1a51921e9f28c1bcec647c2205925bd1fdab • CWE-476: NULL Pointer Dereference •

CVSS: 7.0EPSS: 0%CPEs: 6EXPL: 0

24 Jun 2024 — 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. In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover {reserve,release}_compress_... • https://git.kernel.org/stable/c/c75488fb4d82b697f381f855bf5b16779df440aa • CWE-770: Allocation of Resources Without Limits or Throttling •

CVSS: 7.0EPSS: 0%CPEs: 5EXPL: 0

24 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: don't allow unaligned truncation on released compress inode f2fs image may be corrupted after below testcase: - mkfs.f2fs -O extra_attr,compression -f /dev/vdb - mount /dev/vdb /mnt/f2fs - touch /mnt/f2fs/file - f2fs_io setflags compression /mnt/f2fs/file - dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4 - f2fs_io release_cblocks /mnt/f2fs/file - truncate -s 8192 /mnt/f2fs/file - umount /mnt/f2fs - fsck.f2fs /dev/vdb [ASSERT... • https://git.kernel.org/stable/c/c61404153eb683da9c35aad133131554861ed561 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

24 Jun 2024 — 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_r... • https://git.kernel.org/stable/c/42a359e31a0e438b5b978a8f0fecdbd3c86bb033 • CWE-415: Double Free •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

24 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode() The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating about potential truncation of output when using the snprintf function. The issue was due to the size of the buffer 'ucode_prefix' being too small to accommodate the maximum possible length of the string being written into it. The string being written is "amdgpu/%s_mec.bin" or "amdgp... • https://git.kernel.org/stable/c/86301129698be52f8398f92ea8564168f6bfcae1 • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •

CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0

24 Jun 2024 — 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 propagat... • https://git.kernel.org/stable/c/2875fe0561569f82d0e63658ccf0d11ce7da8922 • CWE-787: Out-of-bounds Write •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

24 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: drm: zynqmp_dpsub: Always register bridge We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning: [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 P... • https://git.kernel.org/stable/c/eb2d64bfcc174919a921295a5327b99a3b8f4166 • CWE-667: Improper Locking •