Page 63 of 3126 results (0.005 seconds)

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: Input: MT - limit max slots syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE). Since nobody knows possible max slots, this patch chose 1024. In the Linux kernel, the following vulnerability has been resolved: Input: MT - limit max slots syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI... • https://git.kernel.org/stable/c/2829c80614890624456337e47320289112785f3e •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: atm: idt77252: prevent use after free in dequeue_rx() We can't dereference "skb" after calling vcc->push() because the skb is released. In the Linux kernel, the following vulnerability has been resolved: atm: idt77252: prevent use after free in dequeue_rx() We can't dereference "skb" after calling vcc->push() because the skb is released. It was discovered that the CIFS network file system implementation in the Linux kernel did not properly ... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: do not clear page dirty inside extent_write_locked_range() [BUG] For subpage + zoned case, the following workload can lead to rsv data leak at unmount time: # mkfs.btrfs -f -s 4k $dev # mount $dev $mnt # fsstress -w -n 8 -d $mnt -s 1709539240 0/0: fiemap - no filename 0/1: copyrange read - no filename 0/2: write - no filename 0/3: rename - no source filename 0/4: creat f0 x:0 0 0 0/4: creat add id=0,parent=-1 0/5: writev f0[259 1 0 0... • https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368 •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Prevent release of buffer in I/O When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time. Handle this situation by not releasing the referenced data buffers if the halt attempt fails. ... • https://git.kernel.org/stable/c/7a7e60ed23d471a07dbbe72565d2992ee8244bbe •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() when freeing tree block after error When freeing a tree block, at btrfs_free_tree_block(), if we fail to create a delayed reference we don't deal with the error and just do a BUG_ON(). The error most likely to happen is -ENOMEM, and we have a comment mentioning that only -ENOMEM can happen, but that is not true, because in case qgroups are enabled any error returned from btrfs_qgroup_trace_extent_post() (can be -EUCLE... • https://git.kernel.org/stable/c/22d907bcd283d69d5e60497fc0d51969545c583b •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Switch from mutex to spinlock for irqfds irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock. Fix it by switching over to a spin lock. In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Switch from mutex to spinlock for irqfds irqfd_wak... • https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Fix racy access to midibuf There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races. In the Linux kernel, the following vulnerability has been resolved: ALSA: line6:... • https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81 •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: parisc: fix a possible DMA corruption ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As ... • https://git.kernel.org/stable/c/00baca74fb5879e5f9034b6156671301f500f8ee •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: x86/mtrr: Check if fixed MTRRs exist before saving them MTRRs have an obsolete fixed variant for fine grained caching control of the 640K-1MB region that uses separate MSRs. This fixed variant has a separate capability bit in the MTRR capability MSR. So far all x86 CPUs which support MTRR have this separate bit set, so it went unnoticed that mtrr_save_state() does not check the capability bit before accessing the fixed MTRR MSRs. Though on ... • https://git.kernel.org/stable/c/2b1f6278d77c1f2f669346fc2bb48012b5e9495a •

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

26 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: fou: remove warn in gue_gro_receive on unsupported protocol Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler. Such a packet is easily constructed. Syzbot generates them and sets off this warning. Remove the warning as it is expected and not actionable. The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive ... • https://git.kernel.org/stable/c/a925a200299a6dfc7c172f54da6f374edc930053 •