Page 49 of 2558 results (0.005 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer. • https://git.kernel.org/stable/c/605572e64cd9cebb05ed609d96cff05b50d18cdf https://git.kernel.org/stable/c/b803f30ea23e0968b6c8285c42adf0d862ab2bf6 https://git.kernel.org/stable/c/3b732449b78183d17178db40be3a4401cf3cd629 https://git.kernel.org/stable/c/89e856e124f9ae548572c56b1b70c2255705f8fe •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport [Why] Potential out of bounds access in dml2_calculate_rq_and_dlg_params() because the value of out_lowest_state_idx used as an index for FCLKChangeSupport array can be greater than 1. [How] Currently dml2 core specifies identical values for all FCLKChangeSupport elements. Always use index 0 in the condition to avoid out of bounds access. • https://git.kernel.org/stable/c/94166fe12543fbef122ca2d093e794ea41073a85 https://git.kernel.org/stable/c/0ad4b4a2f6357c45fbe444ead1a929a0b4017d03 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check bo_va->bo is non-NULL before using it The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. • https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3 https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342 https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536 •

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

In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value in copy_name [syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0. • https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335 https://git.kernel.org/stable/c/c733e24a61cbcff10f660041d6d84d32bb7e4cb4 https://git.kernel.org/stable/c/34f8efd2743f2d961e92e8e994de4c7a2f9e74a0 https://git.kernel.org/stable/c/d02d8c1dacafb28930c39e16d48e40bb6e4cbc70 https://git.kernel.org/stable/c/22999936b91ba545ce1fbbecae6895127945e91c https://git.kernel.org/stable/c/f08956d8e0f80fd0d4ad84ec917302bb2f3a9c6a https://git.kernel.org/stable/c/ad57dc2caf1e0a3c0a9904400fae7afbc9f74bb2 https://git.kernel.org/stable/c/0570730c16307a72f8241df12363f7660 •

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

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix double free in detach The number of the currently released descriptor is never incremented which results in the same skb being released multiple times. • https://git.kernel.org/stable/c/504d4721ee8e432af4b5f196a08af38bc4dac5fe https://git.kernel.org/stable/c/1a2db00a554cfda57c397cce79b2804bf9633fec https://git.kernel.org/stable/c/907443174e76b854d28024bd079f0e53b94dc9a1 https://git.kernel.org/stable/c/22b16618a80858b3a9d607708444426948cc4ae1 https://git.kernel.org/stable/c/69ad5fa0ce7c548262e0770fc2b726fe7ab4f156 https://git.kernel.org/stable/c/c2b66e2b3939af63699e4a4bd25a8ac4a9b1d1b3 https://git.kernel.org/stable/c/9d23909ae041761cb2aa0c3cb1748598d8b6bc54 https://git.kernel.org/stable/c/84aaaa796a19195fc59290154fef9aeb1 •