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: -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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42232 – libceph: fix race between delayed_work() and ceph_monc_stop()
https://notcve.org/view.php?id=CVE-2024-42232
In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed • https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7 https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ec •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42230 – powerpc/pseries: Fix scv instruction crash with kexec
https://notcve.org/view.php?id=CVE-2024-42230
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all. • https://git.kernel.org/stable/c/7fa95f9adaee7e5cbb195d3359741120829e488b https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5 https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3 https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011 •