CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43873 – vhost/vsock: always initialize seqpacket_allow
https://notcve.org/view.php?id=CVE-2024-43873
In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features • https://git.kernel.org/stable/c/ced7b713711fdd8f99d8d04dc53451441d194c60 https://git.kernel.org/stable/c/ea558f10fb05a6503c6e655a1b7d81fdf8e5924c https://git.kernel.org/stable/c/3062cb100787a9ddf45de30004b962035cd497fb https://git.kernel.org/stable/c/30bd4593669443ac58515e23557dc8cef70d8582 https://git.kernel.org/stable/c/eab96e8716cbfc2834b54f71cc9501ad4eec963b https://git.kernel.org/stable/c/1e1fdcbdde3b7663e5d8faeb2245b9b151417d22 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43872 – RDMA/hns: Fix soft lockup under heavy CEQE load
https://notcve.org/view.php?id=CVE-2024-43872
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup under heavy CEQE load CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load. Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler. • https://git.kernel.org/stable/c/a5073d6054f75d7c94b3354206eec4b804d2fbd4 https://git.kernel.org/stable/c/06580b33c183c9f98e2a2ca96a86137179032c08 https://git.kernel.org/stable/c/2fdf34038369c0a27811e7b4680662a14ada1d6b •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43871 – devres: Fix memory leakage caused by driver API devm_free_percpu()
https://notcve.org/view.php?id=CVE-2024-43871
In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). • https://git.kernel.org/stable/c/ff86aae3b4112b85d2231c23bccbc49589df1c06 https://git.kernel.org/stable/c/700e8abd65b10792b2f179ce4e858f2ca2880f85 https://git.kernel.org/stable/c/b044588a16a978cd891cb3d665dd7ae06850d5bf https://git.kernel.org/stable/c/ef56dcdca8f2a53abc3a83d388b8336447533d85 https://git.kernel.org/stable/c/3047f99caec240a88ccd06197af2868da1af6a96 https://git.kernel.org/stable/c/3dcd0673e47664bc6c719ad47dadac6d55d5950d https://git.kernel.org/stable/c/b67552d7c61f52f1271031adfa7834545ae99701 https://git.kernel.org/stable/c/95065edb8ebb27771d5f1e898eef6ab43 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43867 – drm/nouveau: prime: fix refcount underflow
https://notcve.org/view.php?id=CVE-2024-43867
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix refcount underflow Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow. Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually. (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5) • https://git.kernel.org/stable/c/ab9ccb96a6e6f95bcde6b8b2a524370efdbfdcd6 https://git.kernel.org/stable/c/3bcb8bba72ce89667fa863054956267c450c47ef https://git.kernel.org/stable/c/906372e753c5027a1dc88743843b6aa2ad1aaecf https://git.kernel.org/stable/c/16998763c62bb465ebc409d0373b9cdcef1a61a6 https://git.kernel.org/stable/c/ebebba4d357b6c67f96776a48ddbaf0060fa4c10 https://git.kernel.org/stable/c/f23cd66933fe76b84d8e282e5606b4d99068c320 https://git.kernel.org/stable/c/2a1b327d57a8ac080977633a18999f032d7e9e3f https://git.kernel.org/stable/c/a9bf3efc33f1fbf88787a277f73494592 •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43866 – net/mlx5: Always drain health in shutdown callback
https://notcve.org/view.php?id=CVE-2024-43866
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback. • https://git.kernel.org/stable/c/d2aa060d40fa060e963f9a356d43481e43ba3dac https://git.kernel.org/stable/c/63d10e93df94c93bdeac87a9401696b1edadb7ed https://git.kernel.org/stable/c/5005e2e159b300c1b8c6820a1e13a62eb0127b9b https://git.kernel.org/stable/c/6b6c2ebd83f2bf97e8f221479372aaca97a4a9b2 https://git.kernel.org/stable/c/6048dec754554a1303d632be6042d3feb3295285 https://git.kernel.org/stable/c/1b75da22ed1e6171e261bc9265370162553d5393 https://access.redhat.com/security/cve/CVE-2024-43866 https://bugzilla.redhat.com/show_bug.cgi?id=2306358 • CWE-476: NULL Pointer Dereference •