CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41089 – drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
https://notcve.org/view.php?id=CVE-2024-41089
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. • https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51 https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50 https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0 https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637 https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59 https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41082 – nvme-fabrics: use reserved tag for reg read/write command
https://notcve.org/view.php?id=CVE-2024-41082
In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: use reserved tag for reg read/write command In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. • https://git.kernel.org/stable/c/165da9c67a26f08c9b956c15d701da7690f45bcb https://git.kernel.org/stable/c/7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa https://access.redhat.com/security/cve/CVE-2024-41082 https://bugzilla.redhat.com/show_bug.cgi?id=2300459 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41081 – ila: block BH in ila_output()
https://notcve.org/view.php?id=CVE-2024-41081
In the Linux kernel, the following vulnerability has been resolved: ila: block BH in ila_output() As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled. ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock(). We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures. Fix the race by using local_bh_disable(). • https://git.kernel.org/stable/c/7435bd2f84a25aba607030237261b3795ba782da https://git.kernel.org/stable/c/96103371091c6476eb07f4c66624bdd1b42f758a https://git.kernel.org/stable/c/a0cafb7b0b94d18e4813ee4b712a056f280e7b5a https://git.kernel.org/stable/c/feac2391e26b086f73be30e9b1ab215eada8d830 https://git.kernel.org/stable/c/b4eb25a3d70df925a9fa4e82d17a958a0a228f5f https://git.kernel.org/stable/c/522c3336c2025818fa05e9daf0ac35711e55e316 https://git.kernel.org/stable/c/9f9c79d8e527d867e0875868b14fb76e6011e70c https://git.kernel.org/stable/c/cf28ff8e4c02e1ffa850755288ac954b6 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41080 – io_uring: fix possible deadlock in io_register_iowq_max_workers()
https://notcve.org/view.php?id=CVE-2024-41080
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock before acquiring sqd->lock"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock. • https://git.kernel.org/stable/c/b571a367502c7ef94c688ef9c7f7d69a2ce3bcca https://git.kernel.org/stable/c/73254a297c2dd094abec7c9efee32455ae875bdf •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41079 – nvmet: always initialize cqe.result
https://notcve.org/view.php?id=CVE-2024-41079
In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack. • https://git.kernel.org/stable/c/30d35b24b7957922f81cfdaa66f2e1b1e9b9aed2 https://git.kernel.org/stable/c/10967873b80742261527a071954be8b54f0f8e4d https://git.kernel.org/stable/c/0990e8a863645496b9e3f91cfcfd63cd95c80319 https://git.kernel.org/stable/c/cd0c1b8e045a8d2785342b385cb2684d9b48e426 https://access.redhat.com/security/cve/CVE-2024-41079 https://bugzilla.redhat.com/show_bug.cgi?id=2300456 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •