CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-49035 – media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE
https://notcve.org/view.php?id=CVE-2022-49035
In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case. • https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11 https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39 https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4 https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56756 – nvme-pci: fix freeing of the HMB descriptor table
https://notcve.org/view.php?id=CVE-2024-56756
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix freeing of the HMB descriptor table The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent. In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page. • https://git.kernel.org/stable/c/87ad72a59a38d1df217cfd95bc222a2edfe5d399 https://git.kernel.org/stable/c/ac22240540e0c5230d8c4138e3778420b712716a https://git.kernel.org/stable/c/452f9ddd12bebc04cef741e8ba3806bf0e1fd015 https://git.kernel.org/stable/c/869cf50b9c9d1059f5223f79ef68fc0bc6210095 https://git.kernel.org/stable/c/fb96d5cfa97a7363245b3dd523f475b04296d87b https://git.kernel.org/stable/c/cee3bff51a35cab1c5d842d409a7b11caefe2386 https://git.kernel.org/stable/c/6d0f599db73b099aa724a12736369c4d4d92849d https://git.kernel.org/stable/c/582d9ed999b004fb1d415ecbfa86d4d8d •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56755 – netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING
https://notcve.org/view.php?id=CVE-2024-56755
In the Linux kernel, the following vulnerability has been resolved: netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING In fscache_create_volume(), there is a missing memory barrier between the bit-clearing operation and the wake-up operation. This may cause a situation where, after a wake-up, the bit-clearing operation hasn't been detected yet, leading to an indefinite wait. The triggering process is as follows: [cookie1] [cookie2] [volume_work] fscache_perform_lookup fscache_create_volume fscache_perform_lookup fscache_create_volume fscache_create_volume_work cachefiles_acquire_volume clear_and_wake_up_bit test_and_set_bit test_and_set_bit goto maybe_wait goto no_wait In the above process, cookie1 and cookie2 has the same volume. When cookie1 enters the -no_wait- process, it will clear the bit and wake up the waiting process. If a barrier is missing, it may cause cookie2 to remain in the -wait- process indefinitely. In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() in fscache_create_volume_work()"), barriers were added to similar operations in fscache_create_volume_work(), but fscache_create_volume() was missed. By combining the clear and wake operations into clear_and_wake_up_bit() to fix this issue. • https://git.kernel.org/stable/c/bfa22da3ed652aa15acd4246fa13a0de6dbe4a59 https://git.kernel.org/stable/c/ddab02607eed9e415dc62fde421d4329e5345315 https://git.kernel.org/stable/c/539fabba965e119b98066fc6ba5257b5eaf4eda2 https://git.kernel.org/stable/c/8beb682cc9a0798a280bbb95e3e41617237090b2 https://git.kernel.org/stable/c/8cc1df3113cb71a0df2c46dd5b102c9e11c8a8c6 https://git.kernel.org/stable/c/22f9400a6f3560629478e0a64247b8fcc811a24d •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56754 – crypto: caam - Fix the pointer passed to caam_qi_shutdown()
https://notcve.org/view.php?id=CVE-2024-56754
In the Linux kernel, the following vulnerability has been resolved: crypto: caam - Fix the pointer passed to caam_qi_shutdown() The type of the last parameter given to devm_add_action_or_reset() is "struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to "struct device *". Pass the correct parameter to devm_add_action_or_reset() so that the resources are released as expected. • https://git.kernel.org/stable/c/f414de2e2fffd89c8a4e5b5e06b0eba5f9d8b1eb https://git.kernel.org/stable/c/cc386170b3312fd7b5bc4a69a9f52d7f50814526 https://git.kernel.org/stable/c/6187727e57aec122c8a99c464c74578c810cbe40 https://git.kernel.org/stable/c/66eddb8dcb61065c53098510165f14b54232bcc2 https://git.kernel.org/stable/c/1f8e2f597b918ca5827a5c6d00b819d064264d1c https://git.kernel.org/stable/c/84a185aea7b83f620699de0ea36907d588d89cf6 https://git.kernel.org/stable/c/ad39df0898d3f469776c19d99229be055cc2dcea https://git.kernel.org/stable/c/ad980b04f51f7fb503530bd1cb328ba5e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56752 – drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()
https://notcve.org/view.php?id=CVE-2024-56752
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new() When the call to gf100_grctx_generate() fails, unlock gr->fecs.mutex before returning the error. Fixes smatch warning: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns '&gr->fecs.mutex'. • https://git.kernel.org/stable/c/ca081fff6ecc63c86a99918230cc9b947bebae8a https://git.kernel.org/stable/c/237f2dbfa00576bb1aa8dc2dce403c64e53270e6 https://git.kernel.org/stable/c/22b4a623c0f230540f02f4358744cce62ae12dbf https://git.kernel.org/stable/c/24b1df744ef444f9846f52de4985790a5fd1c0de https://git.kernel.org/stable/c/a2f599046c671d6b46d93aed95b37241ce4504cf •