Page 56 of 7030 results (0.008 seconds)

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next bui... • https://git.kernel.org/stable/c/2f32b51b609faea1e40bb8c5bd305f1351740936 •

CVSS: 5.4EPSS: 0%CPEs: 17EXPL: 0

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race. In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_d... • https://git.kernel.org/stable/c/7d267278a9ece963d77eefec61630223fce08c6c •

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ext4: avoid cycles in directory h-tree A maliciously corrupted filesystem can contain cycles in the h-tree stored inside a directory. That can easily lead to the kernel corrupting tree nodes that were already verified under its hands while doing a node split and consequently accessing unallocated memory. Fix the problem by verifying traversed block numbers are unique. In the Linux kernel, the following vulnerability has been resolved: ext4:... • https://git.kernel.org/stable/c/24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3 •

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. In the Linux kernel, the following vulnerability has been resolved: net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register of_get_child_by_name() returns a node pointer with refcount incr... • https://git.kernel.org/stable/c/55954f3bfdacc5908515b0c306cea23e77fab740 •

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a... • https://git.kernel.org/stable/c/db496944fdaaf2a67d2f60529f5dc23abf809506 •

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ip_gre: test csum_start instead of transport header GRE with TUNNEL_CSUM will apply local checksum offload on CHECKSUM_PARTIAL packets. ipgre_xmit must validate csum_start after an optional skb_pull, else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; This had false positives when skb_checksum_start is undefined: when ip_summed is not CHECKSUM_PARTIAL. A discussed re... • https://git.kernel.org/stable/c/774430026bd9a472d08c5d3c33351a782315771a •

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. ... • https://git.kernel.org/stable/c/bf355b8d2c30a289232042cacc1cfaea4923936c •

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules CT cleanup assumes that all tc rules were deleted first, and so is free to delete the CT shared resources (e.g the dr_action fwd_action which is shared for all tuples). But currently for uplink, this is happens in reverse, causing the below trace. CT cleanup is called from: mlx5e_cleanup_rep_tx()->mlx5e_cleanup_uplink_rep_tx()-> mlx5e_rep_tc_cleanup()->mlx5e_tc_esw_cleanup()-> m... • https://git.kernel.org/stable/c/d1a3138f7913014e0714cb1d3d44793d76fc38a1 •

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when ba... • https://git.kernel.org/stable/c/1434cd71ad9f3a6beda3036972983b6c4869207c •

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

26 Feb 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem When the mapping is already reaped the unmap must be a no-op, as we would otherwise try to remove the mapping twice, corrupting the involved data structures. In the Linux kernel, the following vulnerability has been resolved: drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem When the mapping is already reaped the unmap must be a no-op, as we would otherwise try ... • https://git.kernel.org/stable/c/19323b3671a85788569d15685c8f83a05ec48cbb •