Page 100 of 3032 results (0.020 seconds)

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: sched/smt: Fix unbalance sched_smt_present dec/inc I got the following warn report while doing stress test: jump label: negative count! WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Call Trace: __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret... • https://git.kernel.org/stable/c/c5511d03ec090980732e929c318a7a6374b5550e •

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_... • https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute [Why] When unplug one of monitors connected after mst hub, encounter null pointer dereference. It's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When commit new state which directly referring to info stored in dc_sink will cause null pointer dereference. [how] Remove redundant checking condition. Relevant condition should already be cover... • https://git.kernel.org/stable/c/c7e65cab54a89f4df54110f0b44c4ade93d1a911 •

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: li... • https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81 •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: fix TX fifo corruption Sometimes, when a packet is received on channel A at almost the same time as a packet is about to be transmitted on channel B, we observe with a logic analyzer that the received packet on channel A is transmitted on channel B. In other words, the Tx buffer data on channel B is corrupted with data from channel A. The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock t... • https://git.kernel.org/stable/c/4409df5866b7ff7686ba27e449ca97a92ee063c9 •

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

04 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: fix invalid FIFO access with special register set When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading. Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is... • https://git.kernel.org/stable/c/dfeae619d781dee61666d5551b93ba3be755a86b •

CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 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. ... • https://git.kernel.org/stable/c/dadac97f066a67334268132c1e2d0fd599fbcbec •

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... • https://git.kernel.org/stable/c/2b1f6278d77c1f2f669346fc2bb48012b5e9495a •

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

02 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: fuse: Initialize beyond-EOF page contents before setting uptodate fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents). So fuse_notify_store() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate. The current code can leave beyond-EOF page contents uninitialized, wh... • https://github.com/Abdurahmon3236/CVE-2024-44947 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •

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

31 Aug 2024 — In the Linux kernel, the following vulnerability has been resolved: kcm: Serialise kcm_sendmsg() for the same socket. syzkaller reported UAF in kcm_release(). [0] The scenario is 1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb. 2. Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory() 3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue 4. Thread A faces an error and finally frees... • https://github.com/Abdurahmon3236/CVE-2024-44946 •