Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): fix error message<br /> <br /> Sinc commit 79a6d1bfe114 ("can: gs_usb: gs_usb_receive_bulk_callback():<br /> unanchor URL on usb_submit_urb() error") a failing resubmit URB will print<br /> an info message.<br /> <br /> In the case of a short read where netdev has not yet been assigned,<br /> initialize as NULL to avoid dereferencing an undefined value. Also report<br /> the error value of the failed resubmit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efivarfs: fix error propagation in efivar_entry_get()<br /> <br /> efivar_entry_get() always returns success even if the underlying<br /> __efivar_entry_get() fails, masking errors.<br /> <br /> This may result in uninitialized heap memory being copied to userspace<br /> in the efivarfs_file_read() path.<br /> <br /> Fix it by returning the error from __efivar_entry_get().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not strictly require dirty metadata threshold for metadata writepages<br /> <br /> [BUG]<br /> There is an internal report that over 1000 processes are<br /> waiting at the io_schedule_timeout() of balance_dirty_pages(), causing<br /> a system hang and trigger a kernel coredump.<br /> <br /> The kernel is v6.4 kernel based, but the root problem still applies to<br /> any upstream kernel before v6.18.<br /> <br /> [CAUSE]<br /> From Jan Kara for his wisdom on the dirty page balance behavior first.<br /> <br /> This cgroup dirty limit was what was actually playing the role here<br /> because the cgroup had only a small amount of memory and so the dirty<br /> limit for it was something like 16MB.<br /> <br /> Dirty throttling is responsible for enforcing that nobody can dirty<br /> (significantly) more dirty memory than there&amp;#39;s dirty limit. Thus when<br /> a task is dirtying pages it periodically enters into balance_dirty_pages()<br /> and we let it sleep there to slow down the dirtying.<br /> <br /> When the system is over dirty limit already (either globally or within<br /> a cgroup of the running task), we will not let the task exit from<br /> balance_dirty_pages() until the number of dirty pages drops below the<br /> limit.<br /> <br /> So in this particular case, as I already mentioned, there was a cgroup<br /> with relatively small amount of memory and as a result with dirty limit<br /> set at 16MB. A task from that cgroup has dirtied about 28MB worth of<br /> pages in btrfs btree inode and these were practically the only dirty<br /> pages in that cgroup.<br /> <br /> So that means the only way to reduce the dirty pages of that cgroup is<br /> to writeback the dirty pages of btrfs btree inode, and only after that<br /> those processes can exit balance_dirty_pages().<br /> <br /> Now back to the btrfs part, btree_writepages() is responsible for<br /> writing back dirty btree inode pages.<br /> <br /> The problem here is, there is a btrfs internal threshold that if the<br /> btree inode&amp;#39;s dirty bytes are below the 32M threshold, it will not<br /> do any writeback.<br /> <br /> This behavior is to batch as much metadata as possible so we won&amp;#39;t write<br /> back those tree blocks and then later re-COW them again for another<br /> modification.<br /> <br /> This internal 32MiB is higher than the existing dirty page size (28MiB),<br /> meaning no writeback will happen, causing a deadlock between btrfs and<br /> cgroup:<br /> <br /> - Btrfs doesn&amp;#39;t want to write back btree inode until more dirty pages<br /> <br /> - Cgroup/MM doesn&amp;#39;t want more dirty pages for btrfs btree inode<br /> Thus any process touching that btree inode is put into sleep until<br /> the number of dirty pages is reduced.<br /> <br /> Thanks Jan Kara a lot for the analysis of the root cause.<br /> <br /> [ENHANCEMENT]<br /> Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on the<br /> btree_inode"), btrfs btree inode pages will only be charged to the root<br /> cgroup which should have a much larger limit than btrfs&amp;#39; 32MiB<br /> threshold.<br /> So it should not affect newer kernels.<br /> <br /> But for all current LTS kernels, they are all affected by this problem,<br /> and backporting the whole AS_KERNEL_FILE may not be a good idea.<br /> <br /> Even for newer kernels I still think it&amp;#39;s a good idea to get<br /> rid of the internal threshold at btree_writepages(), since for most cases<br /> cgroup/MM has a better view of full system memory usage than btrfs&amp;#39; fixed<br /> threshold.<br /> <br /> For internal callers using btrfs_btree_balance_dirty() since that<br /> function is already doing internal threshold check, we don&amp;#39;t need to<br /> bother them.<br /> <br /> But for external callers of btree_writepages(), just respect their<br /> requests and write back whatever they want, ignoring the internal<br /> btrfs threshold to avoid such deadlock on btree inode dirty page<br /> balancing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: virtuser: fix UAF in configfs release path<br /> <br /> The gpio-virtuser configfs release path uses guard(mutex) to protect<br /> the device structure. However, the device is freed before the guard<br /> cleanup runs, causing mutex_unlock() to operate on freed memory.<br /> <br /> Specifically, gpio_virtuser_device_config_group_release() destroys<br /> the mutex and frees the device while still inside the guard(mutex)<br /> scope. When the function returns, the guard cleanup invokes<br /> mutex_unlock(&amp;dev-&gt;lock), resulting in a slab use-after-free.<br /> <br /> Limit the mutex lifetime by using a scoped_guard() only around the<br /> activation check, so that the lock is released before mutex_destroy()<br /> and kfree() are called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, test_run: Subtract size of xdp_frame from allowed metadata size<br /> <br /> The xdp_frame structure takes up part of the XDP frame headroom,<br /> limiting the size of the metadata. However, in bpf_test_run, we don&amp;#39;t<br /> take this into account, which makes it possible for userspace to supply<br /> a metadata size that is too large (taking up the entire headroom).<br /> <br /> If userspace supplies such a large metadata size in live packet mode,<br /> the xdp_update_frame_from_buff() call in xdp_test_run_init_page() call<br /> will fail, after which packet transmission proceeds with an<br /> uninitialised frame structure, leading to the usual Bad Stuff.<br /> <br /> The commit in the Fixes tag fixed a related bug where the second check<br /> in xdp_update_frame_from_buff() could fail, but did not add any<br /> additional constraints on the metadata size. Complete the fix by adding<br /> an additional check on the metadata size. Reorder the checks slightly to<br /> make the logic clearer and add a comment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: send: check for inline extents in range_is_hole_in_parent()<br /> <br /> Before accessing the disk_bytenr field of a file extent item we need<br /> to check if we are dealing with an inline extent.<br /> This is because for inline extents their data starts at the offset of<br /> the disk_bytenr field. So accessing the disk_bytenr<br /> means we are accessing inline data or in case the inline data is less<br /> than 8 bytes we can actually cause an invalid<br /> memory access if this inline extent item is the first item in the leaf<br /> or access metadata from other items.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure<br /> <br /> When a DAMOS-scheme DAMON sysfs directory setup fails after setup of<br /> access_pattern/ directory, subdirectories of access_pattern/ directory are<br /> not cleaned up. As a result, DAMON sysfs interface is nearly broken until<br /> the system reboots, and the memory for the unremoved directory is leaked.<br /> <br /> Cleanup the directories under such failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: Fix misalignment bug in struct virtnet_info<br /> <br /> Use the new TRAILING_OVERLAP() helper to fix a misalignment bug<br /> along with the following warning:<br /> <br /> drivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]<br /> <br /> This helper creates a union between a flexible-array member (FAM)<br /> and a set of members that would otherwise follow it (in this case<br /> `u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This<br /> overlays the trailing members (rss_hash_key_data) onto the FAM<br /> (hash_key_data) while keeping the FAM and the start of MEMBERS aligned.<br /> The static_assert() ensures this alignment remains.<br /> <br /> Notice that due to tail padding in flexible `struct<br /> virtio_net_rss_config_trailer`, `rss_trailer.hash_key_data`<br /> (at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at<br /> offset 84 in struct virtnet_info) are misaligned by one byte. See<br /> below:<br /> <br /> struct virtio_net_rss_config_trailer {<br /> __le16 max_tx_vq; /* 0 2 */<br /> __u8 hash_key_length; /* 2 1 */<br /> __u8 hash_key_data[]; /* 3 0 */<br /> <br /> /* size: 4, cachelines: 1, members: 3 */<br /> /* padding: 1 */<br /> /* last cacheline: 4 bytes */<br /> };<br /> <br /> struct virtnet_info {<br /> ...<br /> struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */<br /> <br /> /* XXX last struct has 1 byte of padding */<br /> <br /> u8 rss_hash_key_data[40]; /* 84 40 */<br /> ...<br /> /* size: 832, cachelines: 13, members: 48 */<br /> /* sum members: 801, holes: 8, sum holes: 31 */<br /> /* paddings: 2, sum paddings: 5 */<br /> };<br /> <br /> After changes, those members are correctly aligned at offset 795:<br /> <br /> struct virtnet_info {<br /> ...<br /> union {<br /> struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */<br /> struct {<br /> unsigned char __offset_to_hash_key_data[3]; /* 792 3 */<br /> u8 rss_hash_key_data[40]; /* 795 40 */<br /> }; /* 792 43 */<br /> }; /* 792 44 */<br /> ...<br /> /* size: 840, cachelines: 14, members: 47 */<br /> /* sum members: 801, holes: 8, sum holes: 35 */<br /> /* padding: 4 */<br /> /* paddings: 1, sum paddings: 4 */<br /> /* last cacheline: 8 bytes */<br /> };<br /> <br /> As a result, the RSS key passed to the device is shifted by 1<br /> byte: the last byte is cut off, and instead a (possibly<br /> uninitialized) byte is added at the beginning.<br /> <br /> As a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also<br /> moved to the end, since it seems those three members should stick<br /> around together. :)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure<br /> <br /> When a context DAMON sysfs directory setup is failed after setup of attrs/<br /> directory, subdirectories of attrs/ directory are not cleaned up. As a<br /> result, DAMON sysfs interface is nearly broken until the system reboots,<br /> and the memory for the unremoved directory is leaked.<br /> <br /> Cleanup the directories under such failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref<br /> <br /> The error branch for ext4_xattr_inode_update_ref forget to release the<br /> refcount for iloc.bh. Find this when review code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work<br /> <br /> hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling<br /> hci_uart_register_dev(), which calls proto-&gt;open() to initialize<br /> hu-&gt;priv. However, if a TTY write wakeup occurs during this window,<br /> hci_uart_tx_wakeup() may schedule write_work before hu-&gt;priv is<br /> initialized, leading to a NULL pointer dereference in<br /> hci_uart_write_work() when proto-&gt;dequeue() accesses hu-&gt;priv.<br /> <br /> The race condition is:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> hci_uart_set_proto()<br /> set_bit(HCI_UART_PROTO_INIT)<br /> hci_uart_register_dev()<br /> tty write wakeup<br /> hci_uart_tty_wakeup()<br /> hci_uart_tx_wakeup()<br /> schedule_work(&amp;hu-&gt;write_work)<br /> proto-&gt;open(hu)<br /> // initializes hu-&gt;priv<br /> hci_uart_write_work()<br /> hci_uart_dequeue()<br /> proto-&gt;dequeue(hu)<br /> // accesses hu-&gt;priv (NULL!)<br /> <br /> Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto-&gt;open()<br /> succeeds, ensuring hu-&gt;priv is initialized before any work can be<br /> scheduled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zlib: fix the folio leak on S390 hardware acceleration<br /> <br /> [BUG]<br /> After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration<br /> buffer preparation"), we no longer release the folio of the page cache<br /> of folio returned by btrfs_compress_filemap_get_folio() for S390<br /> hardware acceleration path.<br /> <br /> [CAUSE]<br /> Before that commit, we call kumap_local() and folio_put() after handling<br /> each folio.<br /> <br /> Although the timing is not ideal (it release previous folio at the<br /> beginning of the loop, and rely on some extra cleanup out of the loop),<br /> it at least handles the folio release correctly.<br /> <br /> Meanwhile the refactored code is easier to read, it lacks the call to<br /> release the filemap folio.<br /> <br /> [FIX]<br /> Add the missing folio_put() for copy_data_into_buffer().