Page 164 of 4306 results (0.027 seconds)

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: 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: 6.1EPSS: 0%CPEs: 5EXPL: 0

21 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: fix node id validation While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to: BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Stan... • https://git.kernel.org/stable/c/65789daa8087e125927230ccb7e1eab13999b0cf •

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

21 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: handle NUMA_NO_NODE correctly cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_... • https://git.kernel.org/stable/c/65789daa8087e125927230ccb7e1eab13999b0cf • CWE-125: Out-of-bounds Read •

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 •

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

21 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: enic: Validate length of nl attributes in enic_set_vf_port enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID... • https://git.kernel.org/stable/c/f8bd909183acffad68780b10c1cdf36161cfd5d1 •

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

21 Jun 2024 — In the Linux kernel, the following vulnerability has been resolved: greybus: lights: check return of get_channel_from_mode If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru En el kernel de Linux, se resolvió... • https://git.kernel.org/stable/c/2870b52bae4c81823ffcb3ed2b0626fb39d64f48 •