Page 64 of 2930 results (0.008 seconds)

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amster... • https://git.kernel.org/stable/c/830c5aa302ec16b4ee641aec769462c37f802c90 •

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

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: iommu: Fix potential use-after-free during probe Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free. BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1a... • https://git.kernel.org/stable/c/cb86e511e78e796de6947b8f3acca1b7c76fb2ff • CWE-416: Use After Free •

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: 8EXPL: 0

16 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: vsock: remove vsock from connected table when connect is interrupted by a signal vsock_connect() expects that the socket could already be in the TCP_ESTABLISHED state when the connecting task wakes up with a signal pending. If this happens the socket will be in the connected table, and it is not removed when the socket state is reset. In this situation it's common for the process to retry connect(), and if the connection is successful the s... • https://git.kernel.org/stable/c/d021c344051af91f42c5ba9fdedc176740cbd238 • CWE-371: State Issues •