Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: Set object to close if ondemand_id

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: add consistency check for copen/cread<br /> <br /> This prevents malicious processes from completing random copen/cread<br /> requests and crashing the system. Added checks are listed below:<br /> <br /> * Generic, copen can only complete open requests, and cread can only<br /> complete read requests.<br /> * For copen, ondemand_id must not be 0, because this indicates that the<br /> request has not been read by the daemon.<br /> * For cread, the object corresponding to fd and req should be the same.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Fix memory leak in nfs4_set_security_label<br /> <br /> We leak nfs_fattr and nfs4_label every time we set a security xattr.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: fix validation of block size<br /> <br /> Block size should be between 512 and PAGE_SIZE and be a power of 2. The current<br /> check does not validate this, so update the check.<br /> <br /> Without this patch, null_blk would Oops due to a null pointer deref when<br /> loaded with bs=1536 [1].<br /> <br /> <br /> [axboe: remove unnecessary braces and != 0 check]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: qgroup: fix quota root leak after quota disable failure<br /> <br /> If during the quota disable we fail when cleaning the quota tree or when<br /> deleting the root from the root tree, we jump to the &amp;#39;out&amp;#39; label without<br /> ever dropping the reference on the quota root, resulting in a leak of the<br /> root since fs_info-&gt;quota_root is no longer pointing to the root (we have<br /> set it to NULL just before those steps).<br /> <br /> Fix this by always doing a btrfs_put_root() call under the &amp;#39;out&amp;#39; label.<br /> This is a problem that exists since qgroups were first added in 2012 by<br /> commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but<br /> back then we missed a kfree on the quota root and free_extent_buffer()<br /> calls on its root and commit root nodes, since back then roots were not<br /> yet reference counted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: always initialize cqe.result<br /> <br /> The spec doesn&amp;#39;t mandate that the first two double words (aka results)<br /> for the command queue entry need to be set to 0 when they are not<br /> used (not specified). Though, the target implemention returns 0 for TCP<br /> and FC but not for RDMA.<br /> <br /> Let&amp;#39;s make RDMA behave the same and thus explicitly initializing the<br /> result field. This prevents leaking any data from the stack.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix possible deadlock in io_register_iowq_max_workers()<br /> <br /> The io_register_iowq_max_workers() function calls io_put_sq_data(),<br /> which acquires the sqd-&gt;lock without releasing the uring_lock.<br /> Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx-&gt;uring_lock<br /> before acquiring sqd-&gt;lock"), this can lead to a potential deadlock<br /> situation.<br /> <br /> To resolve this issue, the uring_lock is released before calling<br /> io_put_sq_data(), and then it is re-acquired after the function call.<br /> <br /> This change ensures that the locks are acquired in the correct<br /> order, preventing the possibility of a deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ila: block BH in ila_output()<br /> <br /> As explained in commit 1378817486d6 ("tipc: block BH<br /> before using dst_cache"), net/core/dst_cache.c<br /> helpers need to be called with BH disabled.<br /> <br /> ila_output() is called from lwtunnel_output()<br /> possibly from process context, and under rcu_read_lock().<br /> <br /> We might be interrupted by a softirq, re-enter ila_output()<br /> and corrupt dst_cache data structures.<br /> <br /> Fix the race by using local_bh_disable().

Twisted is an event-based framework for internet applications, supporting Python 3.6+. The HTTP 1.0 and 1.1 server provided by twisted.web could process pipelined HTTP requests out-of-order, possibly resulting in information disclosure. This vulnerability is fixed in 24.7.0rc1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: avoid double free special payload<br /> <br /> If a discard request needs to be retried, and that retry may fail before<br /> a new special payload is added, a double free will result. Clear the<br /> RQF_SPECIAL_LOAD when the request is cleaned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: scrub: handle RST lookup error correctly<br /> <br /> [BUG]<br /> When running btrfs/060 with forced RST feature, it would crash the<br /> following ASSERT() inside scrub_read_endio():<br /> <br /> ASSERT(sector_nr nr_sectors);<br /> <br /> Before that, we would have tree dump from<br /> btrfs_get_raid_extent_offset(), as we failed to find the RST entry for<br /> the range.<br /> <br /> [CAUSE]<br /> Inside scrub_submit_extent_sector_read() every time we allocated a new<br /> bbio we immediately called btrfs_map_block() to make sure there was some<br /> RST range covering the scrub target.<br /> <br /> But if btrfs_map_block() fails, we immediately call endio for the bbio,<br /> while the bbio is newly allocated, it&amp;#39;s completely empty.<br /> <br /> Then inside scrub_read_endio(), we go through the bvecs to find<br /> the sector number (as bi_sector is no longer reliable if the bio is<br /> submitted to lower layers).<br /> <br /> And since the bio is empty, such bvecs iteration would not find any<br /> sector matching the sector, and return sector_nr == stripe-&gt;nr_sectors,<br /> triggering the ASSERT().<br /> <br /> [FIX]<br /> Instead of calling btrfs_map_block() after allocating a new bbio, call<br /> btrfs_map_block() first.<br /> <br /> Since our only objective of calling btrfs_map_block() is only to update<br /> stripe_len, there is really no need to do that after btrfs_alloc_bio().<br /> <br /> This new timing would avoid the problem of handling empty bbio<br /> completely, and in fact fixes a possible race window for the old code,<br /> where if the submission thread is the only owner of the pending_io, the<br /> scrub would never finish (since we didn&amp;#39;t decrease the pending_io<br /> counter).<br /> <br /> Although the root cause of RST lookup failure still needs to be<br /> addressed.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.