Page 127 of 6064 results (0.029 seconds)

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

25 Jun 2024 — 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] [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6... • https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0 •

CVSS: 8.8EPSS: 0%CPEs: 1EXPL: 0

25 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: x86/xen: Drop USERGS_SYSRET64 paravirt call commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream. USERGS_SYSRET64 is used to return from a syscall via SYSRET, but a Xen PV guest will nevertheless use the IRET hypercall, as there is no sysret PV hypercall defined. So instead of testing all the prerequisites for doing a sysret and then mangling the stack for Xen PV again for doing an iret just use the iret exit from the beginning. This ca... • https://git.kernel.org/stable/c/cea750c99d8f6391080c420f811a46b21bad7cf4 • CWE-400: Uncontrolled Resource Consumption •

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: 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: 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: 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: 5.5EPSS: 0%CPEs: 9EXPL: 0

21 Jun 2024 — 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_debugf... • https://git.kernel.org/stable/c/a6aa8fca4d792c72947e341d7842d2f700534335 • CWE-667: Improper Locking •

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

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