Page 59 of 2558 results (0.005 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: Fix a deadlock in the error handler The following deadlock has been observed on a test setup: - All tags allocated - The SCSI error handler calls ufshcd_eh_host_reset_handler() - ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler() - ufshcd_err_handler() locks up as follows: Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request. • https://git.kernel.org/stable/c/493c9e850677df8b4eda150c2364b1c1a72ed724 https://git.kernel.org/stable/c/d69d98d8edf90e25e4e09930dd36dd6d09dd6768 https://git.kernel.org/stable/c/945c3cca05d78351bba29fa65d93834cb7934c7b •

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

In the Linux kernel, the following vulnerability has been resolved: xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create If there are failures then we must not leave the non-NULL pointers with the error value, otherwise `rpcrdma_ep_destroy` gets confused and tries free them, resulting in an Oops. • https://git.kernel.org/stable/c/1e7433fb95ccc01629a5edaa4ced0cd8c98d0ae0 https://git.kernel.org/stable/c/9921c866dc369577c3ebb9adf2383b01b58c18de https://git.kernel.org/stable/c/2526d4d8b209dc5ac1fbeb468149774888b2a141 https://git.kernel.org/stable/c/a9c10b5b3b67b3750a10c8b089b2e05f5e176e33 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: change vm->task_info handling This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm. This patch also does logistical changes required for existing usage of vm->task_info. V2: Do not block all the prints when task_info not found (Felix) V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini() V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting • https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c •

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

In the Linux kernel, the following vulnerability has been resolved: netpoll: Fix race condition in netpoll_owner_active KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) <snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU. • https://git.kernel.org/stable/c/43c0ca793a18578a0f5b305dd77fcf7ed99f1265 https://git.kernel.org/stable/c/efd29cd9c7b8369dfc7bcb34637e6bf1a188aa8e https://git.kernel.org/stable/c/96826b16ef9c6568d31a1f6ceaa266411a46e46c https://git.kernel.org/stable/c/3f1a155950a1685ffd0fd7175b3f671da8771f3d https://git.kernel.org/stable/c/a130e7da73ae93afdb4659842267eec734ffbd57 https://git.kernel.org/stable/c/c2e6a872bde9912f1a7579639c5ca3adf1003916 •

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

In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - Fix memory leak for sec resource release The AIV is one of the SEC resources. When releasing resources, it need to release the AIV resources at the same time. Otherwise, memory leakage occurs. The aiv resource release is added to the sec resource release function. • https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2 https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6 https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601 https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47 https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094 •