Page 107 of 2100 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid splat in pskb_pull_reason syzkaller builds (CONFIG_DEBUG_NET=y) frequently trigger a debug hint in pskb_may_pull. We'd like to retain this debug check because it might hint at integer overflows and other issues (kernel code should pull headers, not huge value). In bpf case, this splat isn't interesting at all: such (nonsensical) bpf programs are typically generated by a fuzzer anyway. Do what Eric suggested and suppress such warning. For CONFIG_DEBUG_NET=n we don't need the extra check because pskb_may_pull will do the right thing: return an error without the WARN() backtrace. • https://git.kernel.org/stable/c/8af60bb2b215f478b886f1d6d302fefa7f0b917d https://git.kernel.org/stable/c/1b2b26595bb09febf14c5444c873ac4ec90a5a77 https://git.kernel.org/stable/c/219eee9c0d16f1b754a8b85275854ab17df0850a https://git.kernel.org/stable/c/fff05b2b004d9a8a2416d08647f3dc9068e357c8 https://git.kernel.org/stable/c/dacc15e9cb248d19e5fc63c54bef0b9b55007761 https://git.kernel.org/stable/c/7f9644782c559635bd676c12c59389a34ed7c866 https://git.kernel.org/stable/c/5e90258303a358e88737afb5048bee9113beea3a https://git.kernel.org/stable/c/2bbe3e5a2f4ef69d13be54f1cf895b465 •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

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: 0

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: 0

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: 0

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 •