CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-40995 – net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
https://notcve.org/view.php?id=CVE-2024-40995
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() syzbot found hanging tasks waiting on rtnl_lock [1] A reproducer is available in the syzbot bug. When a request to add multiple actions with the same index is sent, the second request will block forever on the first request. This holds rtnl_lock, and causes tasks to hang. Return -EAGAIN to prevent infinite looping, while keeping documented behavior. [1] INFO: task kworker/1:0:5088 blocked for more than 143 seconds. Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000 Workqueue: events_power_efficient reg_check_chans_work Call Trace: <TASK> context_switch kernel/sched/core.c:5409 [inline] __schedule+0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 [inline] schedule+0xe7/0x350 kernel/sched/core.c:6838 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [inline] reg_leave_invalid_chans net/wireless/reg.c:2466 [inline] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481 • https://git.kernel.org/stable/c/0190c1d452a91c38a3462abdd81752be1b9006a8 https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74 https://git.kernel.org/stable/c/c6a7da65a296745535a964be1019ec7691b0cb90 https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da https://git.kernel.org/stable/c/6fc78d67f51aeb9a542d39a8714e16bc411582d4 https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2 https://git.kernel.org/stable/c/7a0e497b597df7c4cf2b63fc6e9188b6cabe5335 https://git.kernel.org/stable/c/d864319871b05fadd153e0aede4811ca7 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40994 – ptp: fix integer overflow in max_vclocks_store
https://notcve.org/view.php?id=CVE-2024-40994
In the Linux kernel, the following vulnerability has been resolved: ptp: fix integer overflow in max_vclocks_store On 32bit systems, the "4 * max" multiply can overflow. Use kcalloc() to do the allocation to prevent this. • https://git.kernel.org/stable/c/44c494c8e30e35713c7d11ca3c5ab332cbfabacf https://git.kernel.org/stable/c/4b03da87d0b7074c93d9662c6e1a8939f9b8b86e https://git.kernel.org/stable/c/d50d62d5e6ee6aa03c00bddb91745d0b632d3b0f https://git.kernel.org/stable/c/666e934d749e50a37f3796caaf843a605f115b6f https://git.kernel.org/stable/c/e1fccfb4638ee6188377867f6015d0ce35764a8e https://git.kernel.org/stable/c/81d23d2a24012e448f651e007fac2cfd20a45ce0 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40993 – netfilter: ipset: Fix suspicious rcu_dereference_protected()
https://notcve.org/view.php?id=CVE-2024-40993
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Fix suspicious rcu_dereference_protected() When destroying all sets, we are either in pernet exit phase or are executing a "destroy all sets command" from userspace. The latter was taken into account in ip_set_dereference() (nfnetlink mutex is held), but the former was not. The patch adds the required check to rcu_dereference_protected() in ip_set_dereference(). • https://git.kernel.org/stable/c/390b353d1a1da3e9c6c0fd14fe650d69063c95d6 https://git.kernel.org/stable/c/2ba35b37f780c6410bb4bba9c3072596d8576702 https://git.kernel.org/stable/c/90ae20d47de602198eb69e6cd7a3db3420abfc08 https://git.kernel.org/stable/c/788d585e62f487bc4536d454937f737b70d39a33 https://git.kernel.org/stable/c/94dd411c18d7fff9e411555d5c662d29416501e4 https://git.kernel.org/stable/c/3fc09e1ca854bc234e007a56e0f7431f5e2defb5 https://git.kernel.org/stable/c/3799d02ae4208af08e81310770d8754863a246a1 https://git.kernel.org/stable/c/72d9611968867cc4c5509e7708b1507d6 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40992 – RDMA/rxe: Fix responder length checking for UD request packets
https://notcve.org/view.php?id=CVE-2024-40992
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix responder length checking for UD request packets According to the IBA specification: If a UD request packet is detected with an invalid length, the request shall be an invalid request and it shall be silently dropped by the responder. The responder then waits for a new request packet. commit 689c5421bfe0 ("RDMA/rxe: Fix incorrect responder length checking") defers responder length check for UD QPs in function `copy_data`. But it introduces a regression issue for UD QPs. When the packet size is too large to fit in the receive buffer. `copy_data` will return error code -EINVAL. Then `send_data_in` will return RESPST_ERR_MALFORMED_WQE. UD QP will transfer into ERROR state. • https://git.kernel.org/stable/c/689c5421bfe0eac65526bd97a466b9590a6aad3c https://git.kernel.org/stable/c/163868ec1f6c610d16da9e458fe1dd7d5de97341 https://git.kernel.org/stable/c/943c94f41dfe36536dc9aaa12c9efdf548ceb996 https://git.kernel.org/stable/c/f67ac0061c7614c1548963d3ef1ee1606efd8636 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40991 – dmaengine: ti: k3-udma-glue: Fix of_k3_udma_glue_parse_chn_by_id()
https://notcve.org/view.php?id=CVE-2024-40991
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-glue: Fix of_k3_udma_glue_parse_chn_by_id() The of_k3_udma_glue_parse_chn_by_id() helper function erroneously invokes "of_node_put()" on the "udmax_np" device-node passed to it, without having incremented its reference count at any point. Fix it. • https://git.kernel.org/stable/c/81a1f90f20af71728f900f245aa69e9425fdef84 https://git.kernel.org/stable/c/a5ab5f413d1e4c7ed5f64271b025f0726374509e https://git.kernel.org/stable/c/ba27e9d2207784da748b19170a2e56bd7770bd81 •