CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-50189 – HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
https://notcve.org/view.php?id=CVE-2024-50189
In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption. • https://git.kernel.org/stable/c/4b2c53d93a4bc9d52cc0ec354629cfc9dc217f93 https://git.kernel.org/stable/c/8c6ad37e5882073cab84901a31da9cb22f316276 https://git.kernel.org/stable/c/4cd9c5a0fcadc39a05c978a01e15e0d1edc4be93 https://git.kernel.org/stable/c/1c3b4c90479aa0375ec98fe1a802993ff96a5f47 https://git.kernel.org/stable/c/9dfee956f53eea96d93ef1e13ab4ce020f4c58b3 https://git.kernel.org/stable/c/c56f9ecb7fb6a3a90079c19eb4c8daf3bbf514b3 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2024-50188 – net: phy: dp83869: fix memory corruption when enabling fiber
https://notcve.org/view.php?id=CVE-2024-50188
In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed. • https://git.kernel.org/stable/c/a29de52ba2a156873505d8b8cef44e69925b8114 https://git.kernel.org/stable/c/21b5af7f0c99b3bf1fd02016e6708b613acbcaf4 https://git.kernel.org/stable/c/ad0d76b8ee5db063791cc2e7a30ffc9852ac37c4 https://git.kernel.org/stable/c/c1944b4253649fc6f2fb53e7d6302eb414d2182c https://git.kernel.org/stable/c/9ca634676ff66e1d616259e136f96f96b2a1759a https://git.kernel.org/stable/c/e3f2de32dae35bc7d173377dc97b5bc9fcd9fc84 https://git.kernel.org/stable/c/a842e443ca8184f2dc82ab307b43a8b38defd6a5 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-50187 – drm/vc4: Stop the active perfmon before being destroyed
https://notcve.org/view.php?id=CVE-2024-50187
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. • https://git.kernel.org/stable/c/65101d8c9108201118efa7e08f4e2c57f438deb9 https://git.kernel.org/stable/c/75452da51e2403e14be007df80d133e1443fc967 https://git.kernel.org/stable/c/937943c042503dc6087438bf3557f9057a588ba0 https://git.kernel.org/stable/c/c9adba739d5f7cdc47a7754df4a17b47b1ecf513 https://git.kernel.org/stable/c/0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2024-50186 – net: explicitly clear the sk pointer, when pf->create fails
https://notcve.org/view.php?id=CVE-2024-50186
In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling. • https://git.kernel.org/stable/c/78e4aa528a7b1204219d808310524344f627d069 https://git.kernel.org/stable/c/893eeba94c40d513cd0fe6539330ebdaea208c0e https://git.kernel.org/stable/c/454c454ed645fed051216b79622f7cb69c1638f5 https://git.kernel.org/stable/c/6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2 https://git.kernel.org/stable/c/5dfe2408fd7dc4d2e7ac38a116ff0a37b1cfd3b9 https://git.kernel.org/stable/c/daf462ff3cde6ecf22b98d9ae770232c10d28de2 https://git.kernel.org/stable/c/b7d22a79ff4e962b8af5ffe623abd1d6c179eb9f https://git.kernel.org/stable/c/563e6892e21d6ecabdf62103fc4e7b326 •
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 •