Page 24 of 3337 results (0.026 seconds)

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

09 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller number to create array dmub_callback & dmub_thread_offload has potential to access item out of array bound. Fix it. In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] I... • https://git.kernel.org/stable/c/e1896f381d27466c26cb44b4450eae05cd59dfd0 •

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

09 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable DMCUB timeout for DCN35 [Why] DMCUB can intermittently take longer than expected to process commands. Old ASIC policy was to continue while logging a diagnostic error - which works fine for ASIC without IPS, but with IPS this could lead to a race condition where we attempt to access DCN state while it's inaccessible, leading to a system hang when the NIU port is not disabled or register accesses that timeout and the... • https://git.kernel.org/stable/c/31c254c9cd4b122a10db297124f867107a696d83 •

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

27 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: usbnet: ipheth: do not stop RX on failing RX callback RX callbacks can fail for multiple reasons: * Payload too short * Payload formatted incorrecly (e.g. bad NCM framing) * Lack of memory None of these should cause the driver to seize up. Make such failures non-critical and continue processing further incoming URBs. In the Linux kernel, the following vulnerability has been resolved: usbnet: ipheth: do not stop RX on failing RX callback RX ... • https://git.kernel.org/stable/c/4d1cfa3afb8627435744ecdc6d8b58bc72ee0f4c •

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

27 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setup_one_line(). In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in al... • https://git.kernel.org/stable/c/3bedb7ce080690d0d6172db790790c1219bcbdd5 •

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

27 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove SCSI host only if added If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is remov... • https://git.kernel.org/stable/c/2f49e05d6b58d660f035a75ff96b77071b4bd5ed •

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

27 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT retu... • https://git.kernel.org/stable/c/bba47fe3b038cca3d3ebd799665ce69d6d273b58 •

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

27 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() We handle errors here properly, ENOMEM isn't fatal, return the error. Ubuntu Security Notice 7155-1 - Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. • https://git.kernel.org/stable/c/c1406d8329f500e4594cd9730cd313aebc3a4333 •

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

27 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN... • https://git.kernel.org/stable/c/c847b28a799733b04574060ab9d00f215970627d •

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

27 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: ethtool: fail closed if we can't get max channel used in indirection tables Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory. Both of those conditions should be ext... • https://git.kernel.org/stable/c/101737d8b88dbd4be6010bac398fe810f1950036 •

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

27 Sep 2024 — In the Linux kernel, the following vulnerability has been resolved: net: hns3: void array out of bound when loop tnl_num When query reg inf of SSU, it loops tnl_num times. However, tnl_num comes from hardware and the length of array is a fixed value. To void array out of bound, make sure the loop time is not greater than the length of array In the Linux kernel, the following vulnerability has been resolved: net: hns3: void array out of bound when loop tnl_num When query reg inf of SSU, it loops tnl_num time... • https://git.kernel.org/stable/c/c33a9806dc806bcb4a31dc71fb06979219181ad4 •