CVSS: 3.3EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52565 – media: uvcvideo: Fix OOB read
https://notcve.org/view.php?id=CVE-2023-52565
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix OOB read If the index provided by the user is bigger than the mask size, we might do an out of bound read. • https://git.kernel.org/stable/c/367703c3ec4f72208b8cae14310b8a2c955ec565 https://git.kernel.org/stable/c/40140eda661ea4be219ef194a4f43b7b5e3bbd27 https://git.kernel.org/stable/c/42cbbc6b2c39b02e07cbd24dc2155d4edb99dd04 https://git.kernel.org/stable/c/09635bf4cdd4adf2160198a6041bcc7ca46c0558 https://git.kernel.org/stable/c/8bcf70d787f7d53a3b85ad394f926cfef3eed023 https://git.kernel.org/stable/c/41ebaa5e0eebea4c3bac96b72f9f8ae0d77c0bdb https://access.redhat.com/security/cve/CVE-2023-52565 https://bugzilla.redhat.com/show_bug.cgi?id=2267724 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52564 – Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
https://notcve.org/view.php?id=CVE-2023-52564
In the Linux kernel, the following vulnerability has been resolved: Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux" This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239. The commit above is reverted as it did not solve the original issue. gsm_cleanup_mux() tries to free up the virtual ttys by calling gsm_dlci_release() for each available DLCI. There, dlci_put() is called to decrease the reference counter for the DLCI via tty_port_put() which finally calls gsm_dlci_free(). This already clears the pointer which is being checked in gsm_cleanup_mux() before calling gsm_dlci_release(). Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux() as done in the reverted commit. The commit introduces a null pointer dereference: <TASK> ? __die+0x1f/0x70 ? • https://git.kernel.org/stable/c/8fc0eabaa73bbd9bd705577071564616da5c8c61 https://git.kernel.org/stable/c/5138c228311a863c3cf937b94a3ab4c87f1f70c4 https://git.kernel.org/stable/c/9615ca54bc138e35353a001e8b5d4824dce72188 https://git.kernel.org/stable/c/9b9c8195f3f0d74a826077fc1c01b9ee74907239 https://git.kernel.org/stable/c/74a8d6f50cc90ed0061997db51dfa81a62b0f835 https://git.kernel.org/stable/c/6d5c8862932d31a810b6545f7d69ecc124402c6e https://git.kernel.org/stable/c/a48d2bcd23f2c98d575bc2f9b7a3fbd16aeea9eb https://git.kernel.org/stable/c/c61d0b87a7028c2c10faffc524d748334 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52563 – drm/meson: fix memory leak on ->hpd_notify callback
https://notcve.org/view.php?id=CVE-2023-52563
In the Linux kernel, the following vulnerability has been resolved: drm/meson: fix memory leak on ->hpd_notify callback The EDID returned by drm_bridge_get_edid() needs to be freed. • https://git.kernel.org/stable/c/e098989a9219f4456047f9b0e8c44f03e29a843e https://git.kernel.org/stable/c/0af5e0b41110e2da872030395231ab19c45be931 https://git.kernel.org/stable/c/66cb6d74f5a1b6eafe3370b56bf2cb575a91acbc https://git.kernel.org/stable/c/ee335e0094add7fc2c7034e0534e1920d61d2078 https://git.kernel.org/stable/c/43b63e088887a8b82750e16762f77100ffa76cba https://git.kernel.org/stable/c/099f0af9d98231bb74956ce92508e87cbcb896be •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52562 – mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()
https://notcve.org/view.php?id=CVE-2023-52562
In the Linux kernel, the following vulnerability has been resolved: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy() After the commit in Fixes:, if a module that created a slab cache does not release all of its allocated objects before destroying the cache (at rmmod time), we might end up releasing the kmem_cache object without removing it from the slab_caches list thus corrupting the list as kmem_cache_destroy() ignores the return value from shutdown_cache(), which in turn never removes the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails to release all of the cache's slabs. This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y as after that ill release the system will immediately trip on list_add, or list_del, assertions similar to the one shown below as soon as another kmem_cache gets created, or destroyed: [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268) [ 1041.219165] ------------[ cut here ]------------ [ 1041.221517] kernel BUG at lib/list_debug.c:62! [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y, is to set slub_debug to poison the released objects and then just run cat /proc/slabinfo after removing the module that leaks slab objects, in which case the kernel will panic: [ 50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0 This patch fixes this issue by properly checking shutdown_cache()'s return value before taking the kmem_cache_release() branch. • https://git.kernel.org/stable/c/0495e337b7039191dfce6e03f5f830454b1fae6b https://git.kernel.org/stable/c/357321557920c805de2b14832002465c320eea4f https://git.kernel.org/stable/c/a5569bb187521432f509b69dda7d29f78b2d38b0 https://git.kernel.org/stable/c/51988be187b041e5355245957b0b9751fa382e0d https://git.kernel.org/stable/c/46a9ea6681907a3be6b6b0d43776dccc62cad6cf https://access.redhat.com/security/cve/CVE-2023-52562 https://bugzilla.redhat.com/show_bug.cgi?id=2267737 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52561 – arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved
https://notcve.org/view.php?id=CVE-2023-52561
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved Adding a reserved memory region for the framebuffer memory (the splash memory region set up by the bootloader). It fixes a kernel panic (arm-smmu: Unhandled context fault at this particular memory region) reported on DB845c running v5.10.y. • https://git.kernel.org/stable/c/dc1ab6577475b0460ba4261cd9caec37bd62ca0b https://git.kernel.org/stable/c/82dacd0ca0d9640723824026d6fdf773c02de1d2 https://git.kernel.org/stable/c/110e70fccce4f22b53986ae797d665ffb1950aa6 •