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: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42245 – Revert "sched/fair: Make sure to try to detach at least one movable task"
https://notcve.org/view.php?id=CVE-2024-42245
In the Linux kernel, the following vulnerability has been resolved: Revert "sched/fair: Make sure to try to detach at least one movable task" This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06. b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if all tasks examined to that point were pinned. The goal of the patch was to make it more likely to be able to detach a task buried in a long list of pinned tasks. However, this has the unfortunate side effect of creating an O(n) iteration in detach_tasks(), as we now must fully iterate every task on a cpu if all or most are pinned. Since this load balance code is done with rq lock held, and often in softirq context, it is very easy to trigger hard lockups. We observed such hard lockups with a user who affined O(10k) threads to a single cpu. When I discussed this with Vincent he initially suggested that we keep the limit on the number of tasks to detach, but increase the number of tasks we can search. • https://git.kernel.org/stable/c/b0defa7ae03ecf91b8bfd10ede430cff12fcbd06 https://git.kernel.org/stable/c/d467194018dd536fe6c65a2fd3aedfcdb1424903 https://git.kernel.org/stable/c/1e116c18e32b035a2d1bd460800072c8bf96bc44 https://git.kernel.org/stable/c/0fa6dcbfa2e2b97c1e6febbea561badf0931a38b https://git.kernel.org/stable/c/2feab2492deb2f14f9675dd6388e9e2bf669c27a •
CVSS: -EPSS: 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 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42243 – mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray
https://notcve.org/view.php?id=CVE-2024-42243
In the Linux kernel, the following vulnerability has been resolved: mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray Patch series "mm/filemap: Limit page cache size to that supported by xarray", v2. Currently, xarray can't support arbitrary page cache size. More details can be found from the WARN_ON() statement in xas_split_alloc(). In our test whose code is attached below, we hit the WARN_ON() on ARM64 system where the base page size is 64KB and huge page size is 512MB. The issue was reported long time ago and some discussions on it can be found here [1]. [1] https://www.spinics.net/lists/linux-xfs/msg75404.html In order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one supported by xarray and avoid PMD-sized page cache if needed. The code changes are suggested by David Hildenbrand. PATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path PATCH[4] avoids PMD-sized page cache for shmem files if needed Test program ============ # cat test.c #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #include <errno.h> #include <sys/syscall.h> #include <sys/mman.h> #define TEST_XFS_FILENAME "/tmp/data" #define TEST_SHMEM_FILENAME "/dev/shm/data" #define TEST_MEM_SIZE 0x20000000 int main(int argc, char **argv) { const char *filename; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret; if (pgsize ! • https://git.kernel.org/stable/c/793917d997df2e432f3e9ac126e4482d68256d01 https://git.kernel.org/stable/c/a0c42ddd0969fdc760a85e20e267776028a7ca4e https://git.kernel.org/stable/c/333c5539a31f48828456aa9997ec2808f06a699a https://git.kernel.org/stable/c/099d90642a711caae377f53309abfe27e8724a8b https://access.redhat.com/security/cve/CVE-2024-42243 https://bugzilla.redhat.com/show_bug.cgi?id=2303511 • CWE-20: Improper Input Validation •
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 •