CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2024-50185 – mptcp: handle consistently DSS corruption
https://notcve.org/view.php?id=CVE-2024-50185
In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type. • https://git.kernel.org/stable/c/6771bfd9ee2460c13e38c0cd46a3afb5404ae716 https://git.kernel.org/stable/c/fde99e972b8f88cebe619241d7aa43d288ef666a https://git.kernel.org/stable/c/12c1676d598e3b8dd92a033b623b792cc2ea1ec5 https://git.kernel.org/stable/c/35668f8ec84f6c944676e48ecc6bbc5fc8e6fe25 https://git.kernel.org/stable/c/b8be15d1ae7ea4eedd547c3b3141f592fbddcd30 https://git.kernel.org/stable/c/8bfd391bde685df7289b928ce8876a3583be4bfb https://git.kernel.org/stable/c/e32d262c89e2b22cb0640223f953b548617ed8a6 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2024-50184 – virtio_pmem: Check device status before requesting flush
https://notcve.org/view.php?id=CVE-2024-50184
In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated. • https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4 https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4 https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-50183 – scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance
https://notcve.org/view.php?id=CVE-2024-50183
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue. • https://git.kernel.org/stable/c/0857b1c573c0b095aa778bb26d8b3378172471b6 https://git.kernel.org/stable/c/0ef6e016eb53fad6dc44c3253945efb43a3486b9 https://git.kernel.org/stable/c/bbc525409bfe8e5bff12f5d18d550ab3e52cdbef https://git.kernel.org/stable/c/0a3c84f71680684c1d41abb92db05f95c09111e8 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-50182 – secretmem: disable memfd_secret() if arch cannot set direct map
https://notcve.org/view.php?id=CVE-2024-50182
In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. • https://git.kernel.org/stable/c/1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926 https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677 https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2 https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2024-50181 – clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D
https://notcve.org/view.php?id=CVE-2024-50181
In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang. • https://git.kernel.org/stable/c/b677b94a9193ec7b6607bd1255172ae59174a382 https://git.kernel.org/stable/c/d18dc8e14b9c794f58dae1577ccb2ab84a4a1b11 https://git.kernel.org/stable/c/11ceb17e6f07cc30410f3a6276cddda248a9b863 https://git.kernel.org/stable/c/339273a9ddfe7632b717c2e13e81cbd5d383e1ff https://git.kernel.org/stable/c/94f6cdc837e38371324cee97dfd2ef1a99a82c98 https://git.kernel.org/stable/c/a54c441b46a0745683c2eef5a359d22856d27323 •