Page 160 of 2500 results (0.014 seconds)

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: cancel all works upon hci_unregister_dev() syzbot is reporting that calling hci_release_dev() from hci_error_reset() due to hci_dev_put() from hci_error_reset() can cause deadlock at destroy_workqueue(), for hci_error_reset() is called from hdev->req_workqueue which destroy_workqueue() needs to flush. We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are queued into hdev->workqueue and hdev->{power_on,err... • https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9 • CWE-833: Deadlock •

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

29 Jul 2024 — 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 th... • https://git.kernel.org/stable/c/605572e64cd9cebb05ed609d96cff05b50d18cdf •

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

29 Jul 2024 — 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. In the Linux kernel, the follo... • https://git.kernel.org/stable/c/94166fe12543fbef122ca2d093e794ea41073a85 •

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

29 Jul 2024 — 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. 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. Ubuntu Security Notice 7144-1 - Supraja Sridhara, Bene... • https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3 • CWE-20: Improper Input Validation •

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

29 Jul 2024 — 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... • https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335 •

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in fscache_withdraw_volume() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370 Read of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798 CPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565 Call Trace: kasan_check_range+0xf6/0x1b0 ... • https://git.kernel.org/stable/c/fe2140e2f57fef8562e0f9b7cd447d2b08dc2f35 • CWE-416: Use After Free •

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600 Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109 CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566 Call Trace: kasan_report+0x93/0xc... • https://git.kernel.org/stable/c/fe2140e2f57fef8562e0f9b7cd447d2b08dc2f35 • CWE-416: Use After Free •

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files. In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing. In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Use strnlen() on name fields... • https://git.kernel.org/stable/c/f6bc909e7673c30abcbdb329e7d0aa2e83c103d7 • CWE-787: Out-of-bounds Write •

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: mm: prevent derefencing NULL ptr in pfn_section_valid() Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage") changed pfn_section_valid() to add a READ_ONCE() call around "ms->usage" to fix a race with section_deactivate() where ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it. In the Linux kernel, the ... • https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea • CWE-476: NULL Pointer Dereference •

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

29 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix ufshcd_clear_cmd racing issue When ufshcd_clear_cmd is racing with the completion ISR, the completed tag of the request's mq_hctx pointer will be set to NULL by the ISR. And ufshcd_clear_cmd's call to ufshcd_mcq_req_to_hwq will get NULL pointer KE. Return success when the request is completed by ISR because sq does not need cleanup. The racing flow is: Thread A ufshcd_err_handler step 1 ufshcd_try_to_abort_task ufshcd_c... • https://git.kernel.org/stable/c/8d7290348992f27242dd6a696fa2eede709f0b14 •