CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50201 – drm/radeon: Fix encoder->possible_clones
https://notcve.org/view.php?id=CVE-2024-50201
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [... • https://git.kernel.org/stable/c/74d2aacbe84042d89f572a3112a146fca05bfcb1 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50199 – mm/swapfile: skip HugeTLB pages for unuse_vma
https://notcve.org/view.php?id=CVE-2024-50199
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is ... • https://git.kernel.org/stable/c/0fe6e20b9c4c53b3e97096ee73a0857f60aad43f •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50198 – iio: light: veml6030: fix IIO device retrieval from embedded device
https://notcve.org/view.php?id=CVE-2024-50198
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug ... • https://git.kernel.org/stable/c/7b779f573c48e1ad6da1d6ea5f181f3ecd666bf6 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50196 – pinctrl: ocelot: fix system hang on level based interrupts
https://notcve.org/view.php?id=CVE-2024-50196
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt ... • https://git.kernel.org/stable/c/ce8dc0943357a5d10b05dcf0556b537c1d7b8b1f •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50195 – posix-clock: Fix missing timespec64 check in pc_clock_settime()
https://notcve.org/view.php?id=CVE-2024-50195
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consist... • https://git.kernel.org/stable/c/0606f422b453f76c31ab2b1bd52943ff06a2dcf2 •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50194 – arm64: probes: Fix uprobes for big-endian kernels
https://notcve.org/view.php?id=CVE-2024-50194
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously err... • https://git.kernel.org/stable/c/9842ceae9fa8deae141533d52a6ead7666962c09 •
CVSS: 2.1EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50193 – x86/entry_32: Clear CPU buffers after register restore in NMI return
https://notcve.org/view.php?id=CVE-2024-50193
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. In the Linux kernel, the following vulnerability has been resolved: x86/en... • https://git.kernel.org/stable/c/50f021f0b985629accf10481a6e89af8b9700583 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50192 – irqchip/gic-v4: Don't allow a VMOVP on a dying VPE
https://notcve.org/view.php?id=CVE-2024-50192
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp... • https://git.kernel.org/stable/c/64edfaa9a2342a3ce34f8cb982c2c2df84db4de3 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50191 – ext4: don't set SB_RDONLY after filesystem errors
https://notcve.org/view.php?id=CVE-2024-50191
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way ... • https://git.kernel.org/stable/c/fbb177bc1d6487cd3e9b50ae0be2781b7297980d •
CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50189 – HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
https://notcve.org/view.php?id=CVE-2024-50189
08 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption. In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the d... • https://git.kernel.org/stable/c/4b2c53d93a4bc9d52cc0ec354629cfc9dc217f93 •