Page 58 of 3790 results (0.006 seconds)

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: parisc: Fix data TLB miss in sba_unmap_sg Rolf Eike Beer reported the following bug: [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110... • https://git.kernel.org/stable/c/f23f0444ead4d941165aa82ce2fcbb997dc00e97 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: at86rf230: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. In the Tx case we then leak the skb structure. Free the skb structure upon error before returning when appropriate. As the 'is_tx = 0' cannot be moved in the complete handler because of a possible race between the delay in switching to STATE_RX_AACK_ON and a new interrupt, we introdu... • https://git.kernel.org/stable/c/d2a1eaf51b7d4412319adb6acef114ba472d1692 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task Currently a use-after-free may occur if a sas_task is aborted by the upper layer before we handle the I/O completion in mpi_ssp_completion() or mpi_sata_completion(). In this case, the following are the two steps in handling those I/O completions: - Call complete() to inform the upper layer handler of completion of the I/O. - Release driver resources associated with the sas_task ... • https://git.kernel.org/stable/c/fe9ac3eaa2e387a5742b380b73a5a6bc237bf184 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However, if the I/O completion occurs later, the I/O completion still thinks that the sas_task is ava... • https://git.kernel.org/stable/c/d872e7b5fe38f325f5206b6872746fa02c2b4819 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp. The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host,... • https://git.kernel.org/stable/c/a25e460fbb0340488d119fb2e28fe3f829b7417e •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_... • https://git.kernel.org/stable/c/61a26ffd5ad3ece456d74c4c79f7b5e3f440a141 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submi... • https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change The refcount leak issues take place in an error handling path. When the 3rd argument buf doesn't match with "offline", "online" or "remove", the function simply returns -EINVAL and forgets to decrease the reference count of a rpc_xprt object and a rpc_xprt_switch object increased by rpc_sysfs_xprt_kobj_get_xprt() and rpc_sysfs_xprt_kobj_get_xprt_switch(), causing reference... • https://git.kernel.org/stable/c/4b22aa42bd4d2d630ef1854c139275c3532937cb • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: powerpc/fixmap: Fix VM debug warning on unmap Unmapping a fixmap entry is done by calling __set_fixmap() with FIXMAP_PAGE_CLEAR as flags. Today, powerpc __set_fixmap() calls map_kernel_page(). map_kernel_page() is not happy when called a second time for the same page. WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682 NIP: c00... • https://git.kernel.org/stable/c/67baac10dd5ad1e9f50e8f2659984b3b0728d54e • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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

16 Jul 2024 — 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... • https://git.kernel.org/stable/c/493c9e850677df8b4eda150c2364b1c1a72ed724 •