CVSS: 5.5EPSS: %CPEs: 10EXPL: 0CVE-2023-53078 – scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()
https://notcve.org/view.php?id=CVE-2023-53078
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not freed, which will cause following memleak: unreferenced object 0xffff88810b2c6980 (size 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$...... • https://git.kernel.org/stable/c/625fe857e4fac6518716f3c0ff5e5deb8ec6d238 •
CVSS: 7.8EPSS: %CPEs: 5EXPL: 0CVE-2023-53077 – drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes
https://notcve.org/view.php?id=CVE-2023-53077
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes [WHY] When PTEBufferSizeInRequests is zero, UBSAN reports the following warning because dml_log2 returns an unexpected negative value: shift exponent 4294966273 is too large for 32-bit type 'int' [HOW] In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and assign the result directly. In the Linux kernel, the following vulnerability has been resolved: drm/amd/di... • https://git.kernel.org/stable/c/7257070be70e19a9138f39009c1a26c83a8a7cfa •
CVSS: 6.6EPSS: %CPEs: 9EXPL: 0CVE-2023-53076 – bpf: Adjust insufficient default bpf_jit_limit
https://notcve.org/view.php?id=CVE-2023-53076
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: Adjust insufficient default bpf_jit_limit We've seen recent AWS EKS (Kubernetes) user reports like the following: After upgrading EKS nodes from v20230203 to v20230217 on our 1.24 EKS clusters after a few days a number of the nodes have containers stuck in ContainerCreating state or liveness/readiness probes reporting the following error: Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to s... • https://git.kernel.org/stable/c/2d45c6f193789c6b610d734997a2f4cdebec4e37 •
CVSS: 8.5EPSS: %CPEs: 8EXPL: 0CVE-2023-53075 – ftrace: Fix invalid address access in lookup_rec() when index is 0
https://notcve.org/view.php?id=CVE-2023-53075
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix invalid address access in lookup_rec() when index is 0 KASAN reported follow problem: BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly ... • https://git.kernel.org/stable/c/9644302e3315e7e36495d230d5ac7125a316d33e •
CVSS: 7.1EPSS: %CPEs: 3EXPL: 0CVE-2023-53074 – drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini
https://notcve.org/view.php?id=CVE-2023-53074
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini The call trace occurs when the amdgpu is removed after the mode1 reset. During mode1 reset, from suspend to resume, there is no need to reinitialize the ta firmware buffer which caused the bo pin_count increase redundantly. [ 489.885525] Call Trace: [ 489.885525]
CVSS: 5.6EPSS: %CPEs: 3EXPL: 0CVE-2023-53073 – perf/x86/amd/core: Always clear status for idx
https://notcve.org/view.php?id=CVE-2023-53073
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/core: Always clear status for idx The variable 'status' (which contains the unhandled overflow bits) is not being properly masked in some cases, displaying the following warning: WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270 This seems to be happening because the loop is being continued before the status bit being unset, in case x86_perf_event_set_period() returns 0. This is a... • https://git.kernel.org/stable/c/7685665c390dc68c2d9a74e8445f41494cc8f6cf •
CVSS: 5.5EPSS: %CPEs: 3EXPL: 0CVE-2023-53072 – mptcp: use the workqueue to destroy unaccepted sockets
https://notcve.org/view.php?id=CVE-2023-53072
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: mptcp: use the workqueue to destroy unaccepted sockets Christoph reported a UaF at token lookup time after having refactored the passive socket initialization part: BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260 Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PI... • https://git.kernel.org/stable/c/58b09919626bf9067345289212ec030c61eb1034 •
CVSS: 5.5EPSS: %CPEs: 3EXPL: 0CVE-2023-53071 – wifi: mt76: do not run mt76_unregister_device() on unregistered hw
https://notcve.org/view.php?id=CVE-2023-53071
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: do not run mt76_unregister_device() on unregistered hw Trying to probe a mt7921e pci card without firmware results in a successful probe where ieee80211_register_hw hasn't been called. When removing the driver, ieee802111_unregister_hw is called unconditionally leading to a kernel NULL pointer dereference. Fix the issue running mt76_unregister_device routine just for registered hw. In the Linux kernel, the following vulnerabilit... • https://git.kernel.org/stable/c/1c71e03afe4b457a15e50de40006b927dfc00755 •
CVSS: 5.5EPSS: %CPEs: 4EXPL: 0CVE-2023-53070 – ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent
https://notcve.org/view.php?id=CVE-2023-53070
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") enabled to map PPTT once on the first invocation of acpi_get_pptt() and never unmapped the same allowing it to be used at runtime with out the hassle of mapping and unmapping the table. This was needed to fetch LLC information from the PPTT in the cpuhotplug path which is executed in the a... • https://git.kernel.org/stable/c/0c80f9e165f8f9cca743d7b6cbdb54362da297e0 •
CVSS: 5.5EPSS: %CPEs: 4EXPL: 0CVE-2023-53069 – octeontx2-vf: Add missing free for alloc_percpu
https://notcve.org/view.php?id=CVE-2023-53069
02 May 2025 — In the Linux kernel, the following vulnerability has been resolved: octeontx2-vf: Add missing free for alloc_percpu Add the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid memory leak, same as the "pf->hw.lmt_info" in `drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`. In the Linux kernel, the following vulnerability has been resolved: octeontx2-vf: Add missing free for alloc_percpu Add the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid memory leak, same as the "pf->... • https://git.kernel.org/stable/c/5c0512072f6517326d9fba083c4467f173ddd984 •