CVE-2023-52566 – nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()
https://notcve.org/view.php?id=CVE-2023-52566
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly. [konishi.ryusuke@gmail.com: NOTE added to the commit log] • https://git.kernel.org/stable/c/a3d93f709e893187d301aa5458b2248db9f22bd1 https://git.kernel.org/stable/c/fb1084e63ee56958b0a56e17a50a4fd86445b9c1 https://git.kernel.org/stable/c/bb61224f6abc8e71bfdf06d7c984e23460875f5b https://git.kernel.org/stable/c/193b5a1c6c67c36b430989dc063fe7ea4e200a33 https://git.kernel.org/stable/c/7130a87ca32396eb9bf48b71a2d42259ae44c6c7 https://git.kernel.org/stable/c/3936e8714907cd55e37c7cc50e50229e4a9042e8 https://git.kernel.org/stable/c/980663f1d189eedafd18d80053d9cf3e2ceb5c8c https://git.kernel.org/stable/c/28df4646ad8b433340772edc90ca709cd •
CVE-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 •
CVE-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 •
CVE-2023-52559 – iommu/vt-d: Avoid memory allocation in iommu_suspend()
https://notcve.org/view.php?id=CVE-2023-52559
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid memory allocation in iommu_suspend() The iommu_suspend() syscore suspend callback is invoked with IRQ disabled. Allocating memory with the GFP_KERNEL flag may re-enable IRQs during the suspend callback, which can cause intermittent suspend/hibernation problems with the following kernel traces: Calling iommu_suspend+0x0/0x1d0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 ... CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1 RIP: 0010:ktime_get+0x9b/0xb0 ... Call Trace: <IRQ> tick_sched_timer+0x22/0x90 ? __pfx_tick_sched_timer+0x10/0x10 __hrtimer_run_queues+0x111/0x2b0 hrtimer_interrupt+0xfa/0x230 __sysvec_apic_timer_interrupt+0x63/0x140 sysvec_apic_timer_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1f/0x30 ... ------------[ cut here ]------------ Interrupts enabled after iommu_suspend+0x0/0x1d0 WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270 CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1 RIP: 0010:syscore_suspend+0x147/0x270 ... Call Trace: <TASK> hibernation_snapshot+0x25b/0x670 hibernate+0xcd/0x390 state_store+0xcf/0xe0 kobj_attr_store+0x13/0x30 sysfs_kf_write+0x3f/0x50 kernfs_fop_write_iter+0x128/0x200 vfs_write+0x1fd/0x3c0 ksys_write+0x6f/0xf0 __x64_sys_write+0x1d/0x30 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Given that only 4 words memory is needed, avoid the memory allocation in iommu_suspend(). • https://git.kernel.org/stable/c/33e07157105e472b746b70b3ed4197c57c43ab68 https://git.kernel.org/stable/c/29298c85a81abdc512e87537515ed4b1a9601d0e https://git.kernel.org/stable/c/c12ef025add77ca3a0902e8719d552b6d47b4282 https://git.kernel.org/stable/c/496c591f0b389eb782f36d9d4c2564b9a865eed0 https://git.kernel.org/stable/c/59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e •
CVE-2023-52531 – wifi: iwlwifi: mvm: Fix a memory corruption issue
https://notcve.org/view.php?id=CVE-2023-52531
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct ieee80211_channel'. So only 1 element is allocated in this array. When doing: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the 'channels' flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1); because of the "(u8 *)" cast, we add only 1 to the address of the beginning of the flex array. It is likely that we want point at the 'struct ieee80211_rate' allocated just after. Remove the spurious casting so that the pointer arithmetic works as expected. • https://git.kernel.org/stable/c/8ca151b568b67a7b72dcfc6ee6ea7c107ddd795c https://git.kernel.org/stable/c/7c8faa31080342aec4903c9acb20caf82fcca1ef https://git.kernel.org/stable/c/6b3223449c959a8be94a1f042288059e40fcccb0 https://git.kernel.org/stable/c/f06cdd8d4ba5252986f51f80cc30263636397128 https://git.kernel.org/stable/c/8ba438ef3cacc4808a63ed0ce24d4f0942cfe55d •