CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43868 – riscv/purgatory: align riscv_kernel_entry
https://notcve.org/view.php?id=CVE-2024-43868
In the Linux kernel, the following vulnerability has been resolved: riscv/purgatory: align riscv_kernel_entry When alignment handling is delegated to the kernel, everything must be word-aligned in purgatory, since the trap handler is then set to the kexec one. Without the alignment, hitting the exception would ultimately crash. On other occasions, the kernel's handler would take care of exceptions. This has been tested on a JH7110 SoC with oreboot and its SBI delegating unaligned access exceptions and the kernel configured to handle them. • https://git.kernel.org/stable/c/736e30af583fb6e0e2b8211b894ff99dea0f1ee7 https://git.kernel.org/stable/c/5d4aaf16a8255f7c71790e211724ba029609c5ff https://git.kernel.org/stable/c/fb197c5d2fd24b9af3d4697d0cf778645846d6d5 •
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: -EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43865 – s390/fpu: Re-add exception handling in load_fpu_state()
https://notcve.org/view.php?id=CVE-2024-43865
In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Re-add exception handling in load_fpu_state() With the recent rewrite of the fpu code exception handling for the lfpc instruction within load_fpu_state() was erroneously removed. Add it again to prevent that loading invalid floating point register values cause an unhandled specification exception. • https://git.kernel.org/stable/c/8c09871a950a3fe686e0e27fd4193179c5f74f37 https://git.kernel.org/stable/c/494b14138201f07343e5488db6360c828fcc8cf6 https://git.kernel.org/stable/c/4734406c39238cbeafe66f0060084caa3247ff53 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-43864 – net/mlx5e: Fix CT entry update leaks of modify header context
https://notcve.org/view.php?id=CVE-2024-43864
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix CT entry update leaks of modify header context The cited commit allocates a new modify header to replace the old one when updating CT entry. But if failed to allocate a new one, eg. exceed the max number firmware can support, modify header will be an error pointer that will trigger a panic when deallocating it. And the old modify header point is copied to old attr. When the old attr is freed, the old modify header is lost. Fix it by restoring the old attr to attr when failed to allocate a new modify header context. So when the CT entry is freed, the right modify header context will be freed. • https://git.kernel.org/stable/c/94ceffb48eac7692677d8093dcde6965b70c4b35 https://git.kernel.org/stable/c/daab2cc17b6b6ab158566bba037e9551fd432b59 https://git.kernel.org/stable/c/89064d09c56b44c668509bf793c410484f63f5ad https://git.kernel.org/stable/c/025f2b85a5e5a46df14ecf162c3c80a957a36d0b •