Page 17 of 7718 results (0.008 seconds)

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: ima: Fix memory leak in __ima_inode_hash() Commit f3cc6b25dcc5 ("ima: always measure and audit files in policy") lets measurement or audit happen even if the file digest cannot be calculated. As a result, iint->ima_hash could have been allocated despite ima_collect_measurement() returning an error. Since ima_hash belongs to a temporary inode metadata structure, declared at the beginning of __ima_inode_hash(), just add a kfree() call if ima_... • https://git.kernel.org/stable/c/280fe8367b0dc45b6ac5e04fad03e16e99540c0c •

CVSS: 7.1EPSS: 0%CPEs: 9EXPL: 0

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: serial: pch: Fix PCI device refcount leak in pch_request_dma() As comment of pci_get_slot() says, it returns a pci_device with its refcount increased. The caller must decrement the reference count by calling pci_dev_put(). Since 'dma_dev' is only used to filter the channel in filter(), we can call pci_dev_put() before exiting from pch_request_dma(). Add the missing pci_dev_put() for the normal and error path. In the Linux kernel, the follow... • https://git.kernel.org/stable/c/3c6a483275f47a2ef7119309ad3d791c10cf30da •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource() As 'kdata.num' is user-controlled data, if user tries to allocate memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it creates a stack trace and messes up dmesg with a warning. Call trace: -> privcmd_ioctl --> privcmd_ioctl_mmap_resource Add __GFP_NOWARN in order to avoid too large allocation warning. This is detected by static analysis using smatch. In the Linux... • https://git.kernel.org/stable/c/3ad0876554cafa368f574d4d408468510543e9ff •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/omap: dss: Fix refcount leak bugs In dss_init_ports() and __dss_uninit_ports(), we should call of_node_put() for the reference returned by of_graph_get_port_by_id() in fail path or when it is not used anymore. In the Linux kernel, the following vulnerability has been resolved: drm/omap: dss: Fix refcount leak bugs In dss_init_ports() and __dss_uninit_ports(), we should call of_node_put() for the reference returned by of_graph_get_port_b... • https://git.kernel.org/stable/c/09bffa6e519256c6fa1552d6ba1f5d594337a464 •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link() The of_get_next_child() returns a node with refcount incremented, and decrements the refcount of prev. So in the error path of the while loop, of_node_put() needs be called for cpu_ep. In the Linux kernel, the following vulnerability has been resolved: ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link() The of_get_next_child() returns a... • https://git.kernel.org/stable/c/fce9b90c1ab7e915553c57353355700c79b39c86 •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure Now that lockdep is staying enabled through our entire CI runs I started seeing the following stack in generic/475 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0 CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), B... • https://git.kernel.org/stable/c/819a61301275dcc573e3f520be3dc2c8531bee2d •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: platform/chrome: fix memory corruption in ioctl If "s_mem.bytes" is larger than the buffer size it leads to memory corruption. In the Linux kernel, the following vulnerability has been resolved: platform/chrome: fix memory corruption in ioctl If "s_mem.bytes" is larger than the buffer size it leads to memory corruption. The SUSE Linux Enterprise 15 SP5 RT kernel was updated to fix various security issues. • https://git.kernel.org/stable/c/eda2e30c6684d67288edb841c6125d48c608a242 •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: xfrm: Update ipcomp_scratches with NULL when freed Currently if ipcomp_alloc_scratches() fails to allocate memory ipcomp_scratches holds obsolete address. So when we try to free the percpu scratches using ipcomp_free_scratches() it tries to vfree non existent vm area. Described below: static void * __percpu *ipcomp_alloc_scratches(void) { ... scratches = alloc_percpu(void *); if (!scratches) return NULL; ipcomp_scratches does not know about... • https://git.kernel.org/stable/c/debca61df6bc2f65e020656c9c5b878d6b38d30f •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: fix f_hidg lifetime vs cdev The embedded struct cdev does not have its lifetime correctly tied to the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN is held open while the gadget is deleted. This can readily be replicated with libusbgx's example programs (for conciseness - operating directly via configfs is equivalent): gadget-hid exec 3<> /dev/hidg0 gadget-vid-pid-remove exec 3<&- Pull the existing ... • https://git.kernel.org/stable/c/71adf118946957839a13aa4d1094183e05c6c094 •

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

22 Oct 2025 — In the Linux kernel, the following vulnerability has been resolved: fs: jfs: fix shift-out-of-bounds in dbAllocAG Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The underlying bug is the missing check of bmp->db_agl2size. The field can be greater than 64 and trigger the shift-out-of-bounds. Fix this bug by adding a check of bmp->db_agl2size in dbMount since this field is used in many following functions. The upper bound for this field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kl... • https://git.kernel.org/stable/c/d3b486946a4e62c7ef6023f7d9c1d049051384ba •