CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47731 – drivers/perf: Fix ali_drw_pmu driver interrupt status clearing
https://notcve.org/view.php?id=CVE-2024-47731
In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it. • https://git.kernel.org/stable/c/cf7b61073e4526caa247616f6fbb174cbd2a5366 https://git.kernel.org/stable/c/24f30b34ff76648d26872dd4eaa002f074225058 https://git.kernel.org/stable/c/3b839d4619042b02eecdfc986484ac6e6be6acbf https://git.kernel.org/stable/c/062b7176e484678b2c9072d28fbecea47846b274 https://git.kernel.org/stable/c/85702fddba70d2b63f5646793d77de2ad4fc3784 https://git.kernel.org/stable/c/a3dd920977dccc453c550260c4b7605b280b79c3 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47730 – crypto: hisilicon/qm - inject error before stopping queue
https://notcve.org/view.php?id=CVE-2024-47730
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory. • https://git.kernel.org/stable/c/6c6dd5802c2d6769fa589c0e8de54299def199a7 https://git.kernel.org/stable/c/98d3be34c9153eceadb56de50d9f9347e88d86e4 https://git.kernel.org/stable/c/aa3e0db35a60002fb34ef0e4ad203aa59fd00203 https://git.kernel.org/stable/c/f8024f12752e32ffbbf59e1c09d949f977ff743f https://git.kernel.org/stable/c/c5f5b813e546f7fe133539c3d7a5086cc8dd2aa1 https://git.kernel.org/stable/c/b04f06fc0243600665b3b50253869533b7938468 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47728 – bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error
https://notcve.org/view.php?id=CVE-2024-47728
In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. • https://git.kernel.org/stable/c/d7a4cb9b6705a89937d12c8158a35a3145dc967a https://git.kernel.org/stable/c/8397bf78988f3ae9dbebb0200189a62a57264980 https://git.kernel.org/stable/c/a634fa8e480ac2423f86311a602f6295df2c8ed0 https://git.kernel.org/stable/c/599d15b6d03356a97bff7a76155c5604c42a2962 https://git.kernel.org/stable/c/594a9f5a8d2de2573a856e506f77ba7dd2cefc6a https://git.kernel.org/stable/c/4b3786a6c5397dc220b1483d8e2f4867743e966f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47727 – x86/tdx: Fix "in-kernel MMIO" check
https://notcve.org/view.php?id=CVE-2024-47727
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix "in-kernel MMIO" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction. • https://git.kernel.org/stable/c/31d58c4e557d46fa7f8557714250fb6f89c941ae https://git.kernel.org/stable/c/25703a3c980e21548774eea8c8a87a75c5c8f58c https://git.kernel.org/stable/c/4c0c5dcb5471de5fc8f0a1c4980e5815339e1cee https://git.kernel.org/stable/c/18ecd5b74682839e7cdafb7cd1ec106df7baa18c https://git.kernel.org/stable/c/bca2e29f7e26ce7c3522f8b324c0bd85612f68e3 https://git.kernel.org/stable/c/d4fc4d01471528da8a9797a065982e05090e1d81 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-47726 – f2fs: fix to wait dio completion
https://notcve.org/view.php?id=CVE-2024-47726
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode. • https://git.kernel.org/stable/c/e3db757ff9b7101ae68650ac5f6dd5743b68164e https://git.kernel.org/stable/c/96cfeb0389530ae32ade8a48ae3ae1ac3b6c009d •