CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42242 – mmc: sdhci: Fix max_seg_size for 64KiB PAGE_SIZE
https://notcve.org/view.php?id=CVE-2024-42242
In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci: Fix max_seg_size for 64KiB PAGE_SIZE blk_queue_max_segment_size() ensured: if (max_size < PAGE_SIZE) max_size = PAGE_SIZE; whereas: blk_validate_limits() makes it an error: if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE)) return -EINVAL; The change from one to the other, exposed sdhci which was setting maximum segment size too low in some circumstances. Fix the maximum segment size when it is too low. • https://git.kernel.org/stable/c/616f8766179277324393f7b77e07f14cb3503825 https://git.kernel.org/stable/c/bf78b1accef46efd9b624967cb74ae8d3c215a2b https://git.kernel.org/stable/c/63d20a94f24fc1cbaf44d0e7c0e0a8077fde0aef •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42241 – mm/shmem: disable PMD-sized page cache if needed
https://notcve.org/view.php?id=CVE-2024-42241
In the Linux kernel, the following vulnerability has been resolved: mm/shmem: disable PMD-sized page cache if needed For shmem files, it's possible that PMD-sized page cache can't be supported by xarray. For example, 512MB page cache on ARM64 when the base page size is 64KB can't be supported by xarray. It leads to errors as the following messages indicate when this sort of xarray entry is split. WARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 \ nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject \ nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs \ libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \ net_failover virtio_console virtio_blk failover dimlib virtio_mmio CPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff8000882af5f0 x29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768 x26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858 x23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0 x5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xas_split_alloc+0xf8/0x128 split_huge_page_to_list_to_order+0x1c4/0x720 truncate_inode_partial_folio+0xdc/0x160 shmem_undo_range+0x2bc/0x6a8 shmem_fallocate+0x134/0x430 vfs_fallocate+0x124/0x2e8 ksys_fallocate+0x4c/0xa0 __arm64_sys_fallocate+0x24/0x38 invoke_syscall.constprop.0+0x7c/0xd8 do_el0_svc+0xb4/0xd0 el0_svc+0x44/0x1d8 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Fix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger than MAX_PAGECACHE_ORDER. As Matthew Wilcox pointed, the page cache in a shmem file isn't represented by a multi-index entry and doesn't have this limitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache"). A denial of service vulnerability was found in the Linux Kernel. • https://git.kernel.org/stable/c/6b24ca4a1a8d4ee3221d6d44ddbb99f542e4bda3 https://git.kernel.org/stable/c/93893eacb372b0a4a30f7de6609b08c3ba6c4fd9 https://git.kernel.org/stable/c/cd25208ca9b0097f8e079d692fc678f36fdbc3f9 https://git.kernel.org/stable/c/9fd154ba926b34c833b7bfc4c14ee2e931b3d743 https://access.redhat.com/security/cve/CVE-2024-42241 https://bugzilla.redhat.com/show_bug.cgi?id=2303509 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42240 – x86/bhi: Avoid warning in #DB handler due to BHI mitigation
https://notcve.org/view.php?id=CVE-2024-42240
In the Linux kernel, the following vulnerability has been resolved: x86/bhi: Avoid warning in #DB handler due to BHI mitigation When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler (exc_debug_kernel()) to issue a warning because single-step is used outside the entry_SYSENTER_compat() function. To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY after making sure the TF flag is cleared. The problem can be reproduced with the following sequence: $ cat sysenter_step.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); } $ gcc -o sysenter_step sysenter_step.c $ ./sysenter_step Segmentation fault (core dumped) The program is expected to crash, and the #DB handler will issue a warning. Kernel log: WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160 ... RIP: 0010:exc_debug_kernel+0xd2/0x160 ... Call Trace: <#DB> ? show_regs+0x68/0x80 ? __warn+0x8c/0x140 ? • https://git.kernel.org/stable/c/bd53ec80f21839cfd4d852a6088279d602d67e5b https://git.kernel.org/stable/c/07dbb10f153f483e8249acebdffedf922e2ec2e1 https://git.kernel.org/stable/c/eb36b0dce2138581bc6b5e39d0273cb4c96ded81 https://git.kernel.org/stable/c/7390db8aea0d64e9deb28b8e1ce716f5020c7ee5 https://git.kernel.org/stable/c/8f51637712e4da5be410a1666f8aee0d86eef898 https://git.kernel.org/stable/c/db56615e96c439e13783d7715330e824b4fd4b84 https://git.kernel.org/stable/c/a765679defe1dc1b8fa01928a6ad6361e72a1364 https://git.kernel.org/stable/c/dae3543db8f0cf8ac1a198c3bb4b6e3c2 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42239 – bpf: Fail bpf_timer_cancel when callback is being cancelled
https://notcve.org/view.php?id=CVE-2024-42239
In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors. Background on prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status. It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. • https://git.kernel.org/stable/c/b00628b1c7d595ae5b544e059c27b1f5828314b4 https://git.kernel.org/stable/c/9369830518688ecd5b08ffc08ab3302ce2b5d0f7 https://git.kernel.org/stable/c/3e4e8178a8666c56813bd167b848fca0f4c9af0a https://git.kernel.org/stable/c/d4523831f07a267a943f0dde844bf8ead7495f13 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42238 – firmware: cs_dsp: Return error if block header overflows file
https://notcve.org/view.php?id=CVE-2024-42238
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Return error if block header overflows file Return an error from cs_dsp_power_up() if a block header is longer than the amount of data left in the file. The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop while there was enough data left in the file for a valid region. This protected against overrunning the end of the file data, but it didn't abort the file processing with an error. A denial of service vulnerability was found in the Linux kernel. No error was returned from the cs_dsp_power_up() function if a block header is longer than the amount of data left in the file. • https://git.kernel.org/stable/c/f6bc909e7673c30abcbdb329e7d0aa2e83c103d7 https://git.kernel.org/stable/c/b8be70566b33abbd0180105070b4c67cfef8c44f https://git.kernel.org/stable/c/90ab191b7d181057d71234e8632e06b5844ac38e https://git.kernel.org/stable/c/6eabd23383805725eff416c203688b7a390d4153 https://git.kernel.org/stable/c/959fe01e85b7241e3ec305d657febbe82da16a02 https://access.redhat.com/security/cve/CVE-2024-42238 https://bugzilla.redhat.com/show_bug.cgi?id=2303506 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •