CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46678 – bonding: change ipsec_lock from spin lock to mutex
https://notcve.org/view.php?id=CVE-2024-46678
In the Linux kernel, the following vulnerability has been resolved: bonding: change ipsec_lock from spin lock to mutex In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave. [ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] <TASK> [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? • https://git.kernel.org/stable/c/9a5605505d9c7dbfdb89cc29a8f5fc5cf9fd2334 https://git.kernel.org/stable/c/56ccdf868ab6010739a24a3d72c3e53fd0e1ace2 https://git.kernel.org/stable/c/42ec69b9cd7d1f9a8b7420807f3a5d899ca99d28 https://git.kernel.org/stable/c/6b598069164ac1bb60996d6ff94e7f9169dbd2d3 https://git.kernel.org/stable/c/56354b0a2c24a7828eeed7de4b4dc9652d9affa3 https://git.kernel.org/stable/c/2aeeef906d5a526dc60cf4af92eda69836c39b1f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46677 – gtp: fix a potential NULL pointer dereference
https://notcve.org/view.php?id=CVE-2024-46677
In the Linux kernel, the following vulnerability has been resolved: gtp: fix a potential NULL pointer dereference When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case. Fix it by returning an error pointer with the error code carried from sockfd_lookup(). (I found this bug during code inspection.) • https://git.kernel.org/stable/c/1e3a3abd8b28cfda9d0d0167e50e0fe11bc372a9 https://git.kernel.org/stable/c/620fe9809752fae91b4190e897b81ed9976dfb39 https://git.kernel.org/stable/c/bdd99e5f0ad5fa727b16f2101fe880aa2bff2f8e https://git.kernel.org/stable/c/8bbb9e4e0e66a39282e582d0440724055404b38c https://git.kernel.org/stable/c/4643b91691e969b1b9ad54bf552d7a990cfa3b87 https://git.kernel.org/stable/c/e8b9930b0eb045d19e883c65ff9676fc89320c70 https://git.kernel.org/stable/c/28c67f0f84f889fe9f4cbda8354132b20dc9212d https://git.kernel.org/stable/c/612edd35f2a3910ab1f61c1f2338889d4 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46676 – nfc: pn533: Add poll mod list filling check
https://notcve.org/view.php?id=CVE-2024-46676
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Add poll mod list filling check In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero. Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Add poll mod list filling check. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/dfccd0f580445d176acea174175b3e6518cc91f7 https://git.kernel.org/stable/c/c5e05237444f32f6cfe5d907603a232c77a08b31 https://git.kernel.org/stable/c/8ddaea033de051ed61b39f6b69ad54a411172b33 https://git.kernel.org/stable/c/7535db0624a2dede374c42040808ad9a9101d723 https://git.kernel.org/stable/c/7ecd3dd4f8eecd3309432156ccfe24768e009ec4 https://git.kernel.org/stable/c/56ad559cf6d87f250a8d203b555dfc3716afa946 https://git.kernel.org/stable/c/64513d0e546a1f19e390f7e5eba3872bfcbdacf5 https://git.kernel.org/stable/c/febccb39255f9df35527b88c953b2e0de •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46675 – usb: dwc3: core: Prevent USB core invalid event buffer address access
https://notcve.org/view.php?id=CVE-2024-46675
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Prevent USB core invalid event buffer address access This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address. To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address. • https://git.kernel.org/stable/c/eca3f543f817da87c00d1a5697b473efb548204f https://git.kernel.org/stable/c/d2afc2bffec77316b90d530b07695e3f534df914 https://git.kernel.org/stable/c/b72da4d89b97da71e056cc4d1429b2bc426a9c2f https://git.kernel.org/stable/c/111277b881def3153335acfe0d1f43e6cd83ac93 https://git.kernel.org/stable/c/2189fd13c577d7881f94affc09c950a795064c4b https://git.kernel.org/stable/c/7bb11a75dd4d3612378b90e2a4aa49bdccea28ab https://git.kernel.org/stable/c/e23f6ad8d110bf632f7471482e10b43dc174fb72 https://git.kernel.org/stable/c/14e497183df28c006603cc67fd3797a53 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46674 – usb: dwc3: st: fix probed platform device ref count on probe error path
https://notcve.org/view.php?id=CVE-2024-46674
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: st: fix probed platform device ref count on probe error path The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources. • https://git.kernel.org/stable/c/f83fca0707c66e36f14efef7f68702cb12de70b7 https://git.kernel.org/stable/c/b0979a885b9d4df2a25b88e9d444ccaa5f9f495c https://git.kernel.org/stable/c/f3498650df0805c75b4e1c94d07423c46cbf4ce1 https://git.kernel.org/stable/c/6aee4c5635d81f4809c3b9f0c198a65adfbb2ada https://git.kernel.org/stable/c/060f41243ad7f6f5249fa7290dda0c01f723d12d https://git.kernel.org/stable/c/4c6735299540f3c82a5033d35be76a5c42e0fb18 https://git.kernel.org/stable/c/e1e5e8ea2731150d5ba7c707f9e02fafebcfeb49 https://git.kernel.org/stable/c/1de989668708ce5875efc9d669d227212 •