CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44956 – drm/xe/preempt_fence: enlarge the fence critical section
https://notcve.org/view.php?id=CVE-2024-44956
In the Linux kernel, the following vulnerability has been resolved: drm/xe/preempt_fence: enlarge the fence critical section It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm->lock, which is also held when waiting on preempt fences. • https://git.kernel.org/stable/c/458bb83119dfee5d14c677f7846dd9363817006f https://git.kernel.org/stable/c/3cd1585e57908b6efcd967465ef7685f40b2a294 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44955 – drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute
https://notcve.org/view.php?id=CVE-2024-44955
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 covered by checking if dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected. • https://git.kernel.org/stable/c/39b217193729aa45eded8de24d9245468a0c0263 https://git.kernel.org/stable/c/fcf6a49d79923a234844b8efe830a61f3f0584e4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44954 – ALSA: line6: Fix racy access to midibuf
https://notcve.org/view.php?id=CVE-2024-44954
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. • https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81 https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5 https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29 https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747 https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44949 – parisc: fix a possible DMA corruption
https://notcve.org/view.php?id=CVE-2024-44949
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 different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size. • https://git.kernel.org/stable/c/642a0b7453daff0295310774016fcb56d1f5bc7f https://git.kernel.org/stable/c/533de2f470baac40d3bf622fe631f15231a03c9f https://git.kernel.org/stable/c/7ae04ba36b381bffe2471eff3a93edced843240f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44948 – x86/mtrr: Check if fixed MTRRs exist before saving them
https://notcve.org/view.php?id=CVE-2024-44948
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 a CPU that does not support the fixed MTRR capability this results in a #GP. The #GP itself is harmless because the RDMSR fault is handled gracefully, but results in a WARN_ON(). Add the missing capability check to prevent this. • https://git.kernel.org/stable/c/2b1f6278d77c1f2f669346fc2bb48012b5e9495a https://git.kernel.org/stable/c/34f36e6ee5bd7eff8b2adcd9fcaef369f752d82e https://git.kernel.org/stable/c/06c1de44d378ec5439db17bf476507d68589bfe9 https://git.kernel.org/stable/c/450b6b22acdaac67a18eaf5ed498421ffcf10051 https://git.kernel.org/stable/c/ca7d00c5656d1791e28369919e3e10febe9c3b16 https://git.kernel.org/stable/c/8aa79dfb216b865e96ff890bc4ea71650f9bc8d7 https://git.kernel.org/stable/c/8a90d3fc7c24608548d3a750671f9dac21d1a462 https://git.kernel.org/stable/c/388f1c954019f253a8383f7eb733f38d5 •