Page 174 of 3387 results (0.020 seconds)

CVSS: 7.0EPSS: 0%CPEs: 4EXPL: 0

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: net: sched: flower: protect fl_walk() with rcu Patch that refactored fl_walk() to use idr_for_each_entry_continue_ul() also removed rcu protection of individual filters which causes following use-after-free when filter is deleted concurrently. Fix fl_walk() to obtain rcu read lock while iterating and taking the filter reference and temporary release the lock while calling arg->fn() callback that can sleep. KASAN trace: [ 352.773640] =======... • https://git.kernel.org/stable/c/d39d714969cda5cbda291402c8c6b1fb1047f42e •

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

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix stack information leak The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops). Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice. Fixing the ABI is a separa... • https://git.kernel.org/stable/c/ba4dc61fe8c545a5d6a68b63616776556b771f51 •

CVSS: 4.7EPSS: 0%CPEs: 4EXPL: 0

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: net: hns3: do not allow call hns3_nic_net_open repeatedly hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/co... • https://git.kernel.org/stable/c/e888402789b9db5de4fcda361331d66dbf0cd9fd • CWE-664: Improper Control of a Resource Through its Lifetime •

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

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup The ixgbe driver currently generates a NULL pointer dereference with some machine (online cpus < 63). This is due to the fact that the maximum value of num_xdp_queues is nr_cpu_ids. Code is in "ixgbe_set_rss_queues"". Here's how the problem repeats itself: Some machine (online cpus < 63), And user set num_queues to 63 through ethtool. Code is in the "ixgbe_set_channels", adapter->ring_f... • https://git.kernel.org/stable/c/4a9b32f30f805ca596d76605903a48eab58e0b88 •

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

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb We should always check if skb_header_pointer's return is NULL before using it, otherwise it may cause null-ptr-deref, as syzbot reported: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196 Call Trace: sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ... • https://git.kernel.org/stable/c/3acb50c18d8d6650f10919464ade4dcdaf41d62f •

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

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: mac80211-hwsim: fix late beacon hrtimer handling Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx that our handling of the hrtimer here is wrong: If the timer fires late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot) then it tries to actually rearm the timer at the next deadline, which might be in the past already: 1 2 3 N N+1 | | | ... | | ^ intended to fire here (1) ^ next deadline here (2) ^ actually fired h... • https://git.kernel.org/stable/c/01e59e467ecf976c782eecd4dc99644802cc60e2 •

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

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap routine in order to fix the following warning reported by syzbot: WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 Modu... • https://git.kernel.org/stable/c/646e76bb5daf4ca38438c69ffb72cccb605f3466 •

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

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs Fan speed minimum can be enforced from sysfs. For example, setting current fan speed to 20 is used to enforce fan speed to be at 100% speed, 19 - to be not below 90% speed, etcetera. This feature provides ability to limit fan speed according to some system wise considerations, like absence of some replaceable units or high system ambient temperature. Req... • https://git.kernel.org/stable/c/65afb4c8e7e4e7e74b28efa1df62da503ca3e7a6 • CWE-754: Improper Check for Unusual or Exceptional Conditions •

CVSS: 4.7EPSS: 0%CPEs: 3EXPL: 0

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix listener leak in rdma_cma_listen_on_all() failure If cma_listen_on_all() fails it leaves the per-device ID still on the listen_list but the state is not set to RDMA_CM_ADDR_BOUND. When the cmid is eventually destroyed cma_cancel_listens() is not called due to the wrong state, however the per-device IDs are still holding the refcount preventing the ID from being destroyed, thus deadlocking: task:rping state:D stack: 0 pid:19605... • https://git.kernel.org/stable/c/70ba8b1697e35c04ea5f22edb6e401aeb1208d96 •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

21 May 2024 — In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests The FSM can run in a circle allowing rdma_resolve_ip() to be called twice on the same id_priv. While this cannot happen without going through the work, it violates the invariant that the same address resolution background request cannot be active twice. CPU 1 CPU 2 rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(... • https://git.kernel.org/stable/c/e51060f08a61965c4dd91516d82fe90617152590 •