CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42246 – net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
https://notcve.org/view.php?id=CVE-2024-42246
In the Linux kernel, the following vulnerability has been resolved: net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up. Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN. ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request(). • https://git.kernel.org/stable/c/4fbac77d2d092b475dda9eea66da674369665427 https://git.kernel.org/stable/c/bc790261218952635f846aaf90bcc0974f6f62c6 https://git.kernel.org/stable/c/934247ea65bc5eca8bdb7f8c0ddc15cef992a5d6 https://git.kernel.org/stable/c/02ee1976edb21a96ce8e3fd4ef563f14cc16d041 https://git.kernel.org/stable/c/5d8254e012996cee1a0f9cc920531cb7e4d9a011 https://git.kernel.org/stable/c/f2431e7db0fe0daccb2f06bb0d23740affcd2fa6 https://git.kernel.org/stable/c/d6c686c01c5f12ff8f7264e0ddf71df6cb0d4414 https://git.kernel.org/stable/c/f388cfd913a2b96c05339a335f365795d • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42244 – USB: serial: mos7840: fix crash on resume
https://notcve.org/view.php?id=CVE-2024-42244
In the Linux kernel, the following vulnerability has been resolved: USB: serial: mos7840: fix crash on resume Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one. This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure. Fix this by implementing dedicated suspend and resume functions for mos7840. Tested with Delock 87414 USB 2.0 to 4x serial adapter. [ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ] • https://git.kernel.org/stable/c/d83b405383c965498923f3561c3321e2b5df5727 https://git.kernel.org/stable/c/932a86a711c722b45ed47ba2103adca34d225b33 https://git.kernel.org/stable/c/b14aa5673e0a8077ff4b74f0bb260735e7d5e6a4 https://git.kernel.org/stable/c/1094ed500987e67a9d18b0f95e1812f1cc720856 https://git.kernel.org/stable/c/5ae6a64f18211851c8df6b4221381c438b9a7348 https://git.kernel.org/stable/c/553e67dec846323b5575e78a776cf594c13f98c4 https://git.kernel.org/stable/c/c15a688e49987385baa8804bf65d570e362f8576 https://access.redhat.com/security/cve/CVE-2024-42244 • 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') •