Page 48 of 4687 results (0.012 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed • https://git.kernel.org/stable/c/0842ddd83939eb4db940b9af7d39e79722bc41aa https://git.kernel.org/stable/c/6c9915fa9410cbb9bd75ee283c03120046c56d3d https://git.kernel.org/stable/c/697ba0b6ec4ae04afb67d3911799b5e2043b4455 •

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

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count If qi_submit_sync() is invoked with 0 invalidation descriptors (for instance, for DMA draining purposes), we can run into a bug where a submitting thread fails to detect the completion of invalidation_wait. Subsequently, this led to a soft lockup. Currently, there is no impact by this bug on the existing users because no callers are submitting invalidations with 0 descriptors. This fix will enable future users (such as DMA drain) calling qi_submit_sync() with 0 count. Suppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while concurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both threads then enter a while loop, waiting for their respective descriptors to complete. T1 detects its completion (i.e., T1's invalidation_wait status changes to QI_DONE by HW) and proceeds to call reclaim_free_desc() to reclaim all descriptors, potentially including adjacent ones of other threads that are also marked as QI_DONE. During this time, while T2 is waiting to acquire the qi->q_lock, the IOMMU hardware may complete the invalidation for T2, setting its status to QI_DONE. • https://git.kernel.org/stable/c/de9e7f68762585f7532de8a06de9485bf39dbd38 https://git.kernel.org/stable/c/8840dc73ac9e1028291458ef1429ec3c2524ffec https://git.kernel.org/stable/c/e03f00aa4a6c0c49c17857a4048f586636abdc32 https://git.kernel.org/stable/c/dfdbc5ba10fb792c9d6d12ba8cb6e465f97365ed https://git.kernel.org/stable/c/07e4e92f84b7d3018b7064ef8d8438aeb54a2ca5 https://git.kernel.org/stable/c/92ba5b014d5435dd7a1ee02a2c7f2a0e8fe06c36 https://git.kernel.org/stable/c/3cf74230c139f208b7fb313ae0054386eee31a81 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/ • https://git.kernel.org/stable/c/d02611ff001454358be6910cb926799e2d818716 https://git.kernel.org/stable/c/0a1741d10da29aa84955ef89ae9a03c4b6038657 https://git.kernel.org/stable/c/454e5d7e671946698af0f201e48469e5ddb42851 https://git.kernel.org/stable/c/b22eec4b57d04befa90e8554ede34e6c67257606 https://git.kernel.org/stable/c/19dd9780b7ac673be95bf6fd6892a184c9db611f •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug. • https://git.kernel.org/stable/c/30ceb873cc2e97348d9da2265b2d1ddf07f682e1 https://git.kernel.org/stable/c/71f3240f82987f0f070ea5bed559033de7d4c0e1 https://git.kernel.org/stable/c/6c9289806591807e4e3be9a23df8ee2069180055 https://git.kernel.org/stable/c/c86ad39140bbcb9dc75a10046c2221f657e8083b •

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

In the Linux kernel, the following vulnerability has been resolved: drm/xe/hdcp: Check GSC structure validity Sometimes xe_gsc is not initialized when checked at HDCP capability check. Add gsc structure check to avoid null pointer error. • https://git.kernel.org/stable/c/c940627857eedca8407b84b40ceb4252b100d291 https://git.kernel.org/stable/c/7266a424b1e502745170322e3c27f697d12de627 https://git.kernel.org/stable/c/b4224f6bae3801d589f815672ec62800a1501b0d •