CVE-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 •
CVE-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 •
CVE-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') •
CVE-2024-41078 – btrfs: qgroup: fix quota root leak after quota disable failure
https://notcve.org/view.php?id=CVE-2024-41078
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix quota root leak after quota disable failure If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps). Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted. • https://git.kernel.org/stable/c/94818bdb00ef34a996a06aa63d11f591074cb757 https://git.kernel.org/stable/c/8a69529f22590b67bb018de9acbcf94abc8603cf https://git.kernel.org/stable/c/5ef3961682e5310f2221bae99bcf9f5d0f4b0d51 https://git.kernel.org/stable/c/f88aeff5a173e8ba3133314eb4b964236ef3589d https://git.kernel.org/stable/c/7dd6a5b96157a21245566b21fd58276a214357ff https://git.kernel.org/stable/c/a7e4c6a3031c74078dba7fa36239d0f4fe476c53 •
CVE-2024-41077 – null_blk: fix validation of block size
https://notcve.org/view.php?id=CVE-2024-41077
In the Linux kernel, the following vulnerability has been resolved: null_blk: fix validation of block size Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check. Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1]. [axboe: remove unnecessary braces and != 0 check] • https://git.kernel.org/stable/c/9625afe1dd4a158a14bb50f81af9e2dac634c0b1 https://git.kernel.org/stable/c/9b873bdaae64bddade9d8c6df23c8a31948d47d0 https://git.kernel.org/stable/c/2772ed2fc075eef7df3789906fc9dae01e4e132e https://git.kernel.org/stable/c/08f03186b96e25e3154916a2e70732557c770ea7 https://git.kernel.org/stable/c/f92409a9da02f27d05d713bff5f865e386cef9b3 https://git.kernel.org/stable/c/c462ecd659b5fce731f1d592285832fd6ad54053 https://access.redhat.com/security/cve/CVE-2024-41077 https://bugzilla.redhat.com/show_bug.cgi?id=2300454 • CWE-476: NULL Pointer Dereference •