CVSS: -EPSS: 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 •
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: -EPSS: 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. • 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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42237 – firmware: cs_dsp: Validate payload length before processing block
https://notcve.org/view.php?id=CVE-2024-42237
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Validate payload length before processing block Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it. • https://git.kernel.org/stable/c/f6bc909e7673c30abcbdb329e7d0aa2e83c103d7 https://git.kernel.org/stable/c/259955eca9b7acf1299b1ac077d8cfbe12df35d8 https://git.kernel.org/stable/c/3a9cd924aec1288d675df721f244da4dd7e16cff https://git.kernel.org/stable/c/71d9e313d8f7e18c543a9c80506fe6b1eb1fe0c8 https://git.kernel.org/stable/c/6598afa9320b6ab13041616950ca5f8f938c0cf1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42236 – usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()
https://notcve.org/view.php?id=CVE-2024-42236
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form `if (str[0 - 1] == '\n') followed closely by an OOB write in the form `str[0 - 1] = '\0'`. There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short. • https://git.kernel.org/stable/c/a444c3fc264119801575ab086e03fb4952f23fd0 https://git.kernel.org/stable/c/c95fbdde87e39e5e0ae27f28bf6711edfb985caa https://git.kernel.org/stable/c/e8474a10c535e6a2024c3b06e37e4a3a23beb490 https://git.kernel.org/stable/c/72b8ee0d9826e8ed00e0bdfce3e46b98419b37ce https://git.kernel.org/stable/c/2d16f63d8030903e5031853e79d731ee5d474e70 https://git.kernel.org/stable/c/d1205033e912f9332c1dbefa812e6ceb0575ce0a https://git.kernel.org/stable/c/eecfefad0953b2f31aaefa058f7f348ff39c4bba https://git.kernel.org/stable/c/6d3c721e686ea6c59e18289b400cc95c7 •