Page 193 of 6393 results (0.013 seconds)

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: tracing/osnoise: Do not unregister events twice Nicolas reported that using: # trace-cmd record -e all -M 10 -p osnoise --poll Resulted in the following kernel warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370 [...] CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19 RIP: 0010:tracepoint_probe_unregister+0x280/0x370 [...] CR2... • https://git.kernel.org/stable/c/2fac8d6486d5c34e2ec7028580142b8209da3f92 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: watch_queue: Fix filter limit check In watch_queue_set_filter(), there are a couple of places where we check that the filter type value does not exceed what the type_filter bitmap can hold. One place calculates the number of bits by: if (tf[i].type >= sizeof(wfilter->type_filter) * 8) which is fine, but the second does: if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG) which is not. This can lead to a couple of out-of-bounds w... • https://git.kernel.org/stable/c/c73be61cede5882f9605a852414db559c0ebedfd • CWE-787: Out-of-bounds Write •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: block: release rq qos structures for queue without disk blkcg_init_queue() may add rq qos structures to request queue, previously blk_cleanup_queue() calls rq_qos_exit() to release them, but commit 8e141f9eb803 ("block: drain file system I/O on del_gendisk") moves rq_qos_exit() into del_gendisk(), so memory leak is caused because queues may not have disk, such as un-present scsi luns, nvme admin queue, ... Fixes the issue by adding rq_qos_e... • https://git.kernel.org/stable/c/8e141f9eb803e209714a80aa6ec073893f94c526 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: MIPS: smp: fill in sibling and core maps earlier After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following: [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) [ 0.048183] ------------[ cut here ]------------ [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [ 0.048220] Modules linked in: [ 0.04823... • https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix leaking sent_cmd skb sent_cmd memory is not freed before freeing hci_dev causing it to leak it contents. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix leaking sent_cmd skb sent_cmd memory is not freed before freeing hci_dev causing it to leak it contents. • https://git.kernel.org/stable/c/3679ccc09d8806686d579095ed504e045af7f7d6 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/vrr: Set VRR capable prop only if it is attached to connector VRR capable property is not attached by default to the connector It is attached only if VRR is supported. So if the driver tries to call drm core set prop function without it being attached that causes NULL dereference. In the Linux kernel, the following vulnerability has been resolved: drm/vrr: Set VRR capable prop only if it is attached to connector VRR capable property is ... • https://git.kernel.org/stable/c/941e8bcd2b2ba95490738e33dfeca27168452779 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: ice: Fix race condition during interface enslave Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating auxiliary device") changes a process of re-creation of aux device so ice_plug_aux_dev() is called from ice_service_task() context. This unfortunately opens a race window that can result in dead-lock when interface has left LAG and immediately enters LAG again. Reproducer: ``` #!/bin/sh ip link add lag0 type bond mode 1 miimon 100 i... • https://git.kernel.org/stable/c/a9bbacc53d1f5ed8febbfdf31401d20e005f49ef • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-667: Improper Locking •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats() It is possible to do NULL pointer dereference in routine that updates Tx ring stats. Currently only stats and bytes are updated when ring pointer is valid, but later on ring is accessed to propagate gathered Tx stats onto VSI stats. Change the existing logic to move to next ring when ring is NULL. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corri... • https://git.kernel.org/stable/c/e72bba21355dbb67512a0d666fec9f4b56dbfc2f • CWE-476: NULL Pointer Dereference •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: iavf: Fix hang during reboot/shutdown Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets it... • https://git.kernel.org/stable/c/85aa76066fef64de8a48d0da6b4071ceac455a94 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: net/packet: fix slab-out-of-bounds access in packet_recvmsg() syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH and mmap operations, tpacket_rcv() is queueing skbs with garbage in skb->cb[], triggering a too big copy [1] Presumably, users of af_packet using mmap() already gets correct metadata from the mapped buffer, we can simply make sure to clear 12 bytes that might be copied to user space later. BUG: KASAN: stack-ou... • https://git.kernel.org/stable/c/0fb375fb9b93b7d822debc6a734052337ccfdb1f • CWE-125: Out-of-bounds Read •