Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: don&amp;#39;t walk off the end of a null sc-&gt;sa.agi_bp in AGI repair<br /> <br /> LOLLM noticed a longstanding bug where xrep_iunlink_walk_ondisk_bucket<br /> tries to walk ragi-&gt;sc-&gt;sa.agi_bp to rebuild the unlinked inode lists.<br /> Unfortunately, it&amp;#39;s possible for agi_bp to be null if the buffer<br /> verifier fails, so we have to use ragi-&gt;agi_bp (which skips verifier<br /> checks) instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: don&amp;#39;t double-lock when deleting a self-referential directory<br /> <br /> LOLLM notices that the dirtree scrubber can detect a directory that<br /> refers to itself. In this case, it&amp;#39;s not correct for the directory tree<br /> repair code to try to iolock/ilock both sc-&gt;ip and dp, because they&amp;#39;re<br /> the same inode. Fix this by detecting that corner case and handling it<br /> appropriately.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: tas2562: Validate values for volume writes<br /> <br /> tas2562_volume_control_put() does not do any validation of the control<br /> value written by userspace, it uses it to look up a value in a fixed<br /> size array which can easily be overflowed and then writes whatever value<br /> it gets back to the device. Add validation that we are loading a value<br /> we have in the array.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix hanging __ceph_get_caps() with stale mds_wanted<br /> <br /> A reader can hang forever in __ceph_get_caps() when the client no<br /> longer holds `FILE_RD`, but local cap state still says that the<br /> capability is already wanted (via `mds_wanted`).<br /> <br /> One way to trigger this is through MDS cap revocation. If another<br /> client performs a conflicting operation, the MDS can revoke `FILE_RD`<br /> from the reader; the next read then has to reacquire `FILE_RD`. If<br /> the cap update that should request `FILE_RD` never reaches the MDS<br /> after `cap-&gt;mds_wanted` was raised, the reader is left holding only<br /> non-file caps while local `mds_wanted` still includes the file read<br /> caps.<br /> <br /> In that state, try_get_cap_refs() sees `need mds_wanted was` raised, no further request is sent and the<br /> waiter can sleep indefinitely until unrelated cap traffic happens to<br /> wake it up.<br /> <br /> The ordering issue is that `cap-&gt;mds_wanted` is updated in<br /> __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually<br /> queued for send. That makes one field serve two different meanings at<br /> once: what this client wants, and what the client believes the MDS<br /> already knows it wants.<br /> <br /> A proper fix would be to split those states and track whether a cap<br /> update is actually in flight or has been observed by the MDS.<br /> However, simply moving the `cap-&gt;mds_wanted assignment` later would<br /> not be sufficient: queueing the message in the messenger does not<br /> guarantee that the MDS processed that specific wanted set, and<br /> reconnect or message loss can still invalidate that assumption.<br /> Fixing that properly would require a larger rework of the cap state<br /> machine.<br /> <br /> To allow simpler backports to stable kernels, this patch implements a<br /> simpler workaround:<br /> <br /> - stop waiting forever in __ceph_get_caps(); after a bounded wait,<br /> fall back to the renew path<br /> <br /> - make ceph_renew_caps() issue a synchronous `OPEN` request whenever<br /> the inode still does not actually hold the wanted caps, instead of<br /> only calling ceph_check_caps()<br /> <br /> The extra issued-vs-wanted check in ceph_renew_caps() is necessary<br /> because the previous test only checked whether the inode still had any<br /> real caps at all. That is not enough after revocation: the client can<br /> still hold something like `pLs` and yet be missing `FILE_RD`<br /> completely. In that case, falling back to ceph_check_caps() is not<br /> sufficient, because it still trusts `cap-&gt;mds_wanted` and may resend<br /> nothing. By requiring `(issued &amp; wanted) == wanted` before taking the<br /> asynchronous path, the code only uses ceph_check_caps() when the<br /> `wanted caps` are already actually issued. Otherwise, it sends the<br /> synchronous `OPEN` renew.<br /> <br /> This preserves the existing asynchronous fast path when the wanted<br /> caps are already issued, avoids changing cap-state semantics, and<br /> fixes the hang by guaranteeing that a stalled waiter eventually<br /> retries through a path that does not rely on the stale `mds_wanted`<br /> state.<br /> <br /> [ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to<br /> mds_client.h, formatting ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: avoid fs reclaim while using current-&gt;journal_info<br /> <br /> handle_reply() stores a `ceph_mds_request` pointer in<br /> `current-&gt;journal_info` while filling the inode and dentry cache from<br /> an MDS reply.<br /> <br /> An allocation in this section can enter direct reclaim and prune<br /> dentries from another filesystem. If this dirties an ext4 inode, ext4<br /> starts a JBD2 transaction. JBD2 interprets the Ceph request in<br /> `current-&gt;journal_info` as a journal handle and dereferences the<br /> request&amp;#39;s `r_tid` as `h_transaction`, causing a kernel crash, e.g.:<br /> <br /> Unable to handle kernel paging request at virtual address 00000000077b4818<br /> [...]<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Modules linked in:<br /> CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE<br /> [...]<br /> Workqueue: ceph-msgr ceph_con_workfn<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : jbd2__journal_start+0x2c/0x208<br /> lr : __ext4_journal_start_sb+0x100/0x178<br /> [...]<br /> Call trace:<br /> jbd2__journal_start+0x2c/0x208 (P)<br /> __ext4_journal_start_sb+0x100/0x178<br /> ext4_dirty_inode+0x3c/0x90<br /> __mark_inode_dirty+0x58/0x400<br /> iput.part.0+0x2b0/0x370<br /> iput+0x18/0x30<br /> dentry_unlink_inode+0xc0/0x158<br /> __dentry_kill+0x80/0x250<br /> shrink_dentry_list+0x90/0x130<br /> prune_dcache_sb+0x60/0x98<br /> super_cache_scan+0xe8/0x190<br /> do_shrink_slab+0x174/0x388<br /> shrink_slab+0xd8/0x4c0<br /> shrink_node+0x31c/0x908<br /> do_try_to_free_pages+0xd0/0x508<br /> try_to_free_pages+0x11c/0x238<br /> __alloc_frozen_pages_noprof+0x4d0/0xdd0<br /> __folio_alloc_noprof+0x18/0x70<br /> __filemap_get_folio+0x248/0x440<br /> ceph_readdir_prepopulate+0x570/0x9e8<br /> mds_dispatch+0x1424/0x1ba0<br /> ceph_con_process_message+0x74/0xa0<br /> ceph_con_v1_try_read+0x3a0/0x1510<br /> ceph_con_workfn+0x260/0x460<br /> <br /> Enter a scoped NOFS allocation context and leave it after clearing<br /> `journal_info`. This prevents filesystem reclaim from recursing into<br /> another filesystem while the field contains Ceph-private data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN<br /> <br /> When exchanging two full-file ranges, xmi_can_exchange_reflink_flags()<br /> can move the reflink inode flag from the file that currently has it to<br /> the other file, as long as exactly one side is marked. This assumes<br /> that the file contents, and therefore all shared extents, are exchanged.<br /> <br /> That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set.<br /> xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings<br /> from file1, so an exchange can complete without moving every mapping<br /> that the earlier flag-swap decision accounted for. In that case the<br /> post-operation cleanup can clear the reflink flag from an inode that<br /> still owns shared written extents. Later writes then take the<br /> non-reflink write path and may update blocks that should still have<br /> been protected by CoW, which shows up as data corruption between<br /> reflink-related files.<br /> <br /> Fix this by disabling the reflink flag exchange whenever<br /> XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still<br /> proceed; the conservative outcome is that both inodes keep the reflink<br /> flag. The regular reflink flag cleanup path can drop the extra flag<br /> later once the inode no longer has shared extents.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> optee: ffa: Add NULL check in optee_ffa_lend_protmem<br /> <br /> Sashiko (locally) reports a possible null dereference under memory<br /> pressure due to the lack of validation of the allocated pointer.<br /> <br /> Fix that by adding the missing check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-topology: Refresh copier IPC payload before widget setup<br /> <br /> The ipc_config_data buffer for copier widgets is built once during<br /> ipc_prepare (called from sof_pcm_setup_connected_widgets) and cached<br /> for reuse. For host copiers this buffer contains the copier_data with<br /> gtw_cfg.node_id (host DMA ID). For DAI copiers it additionally includes<br /> a dma_config_tlv trailer with stream_id and dma_channel_id for HDA link<br /> DMA.<br /> <br /> On suspend/resume, both host and link DMA streams are released and<br /> re-allocated with potentially different stream tags. The underlying<br /> copier_data and dma_config_tlv structures are correctly updated by<br /> host_config and sdw_hda_dai_hw_params respectively. However, since the<br /> widget list (spcm-&gt;stream[].list) persists across suspend,<br /> sof_pcm_hw_params skips sof_pcm_setup_connected_widgets and ipc_prepare<br /> never runs again to rebuild ipc_config_data. The stale cached payload<br /> is then sent to firmware with boot-time DMA channel assignments, causing<br /> DMA channel conflicts that lead to firmware errors and crashes.<br /> <br /> Fix this by refreshing copier_data and dma_config_tlv portions of<br /> ipc_config_data in sof_ipc4_widget_setup right before the IPC message<br /> is sent. This ensures the payload always reflects the current DMA state<br /> regardless of whether ipc_prepare ran.<br /> <br /> For DAI copiers, the gtw_cfg.config_length in copier_data is temporarily<br /> inflated to include the TLV size (matching the ipc_config_data layout)<br /> before copying, then restored, mirroring what<br /> sof_ipc4_prepare_copier_module does when first building the buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: don&amp;#39;t swallow dquot recovery verification errors<br /> <br /> xlog_recover_dquot_commit_pass2() validates the recovered dquot with<br /> xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps<br /> to out_release. But out_release unconditionally returns 0, so the<br /> corruption error is discarded: the caller xlog_recover_items_pass2()<br /> sees success, log recovery proceeds as if the dquot were valid, and the<br /> corrupt quota buffer can be written back to disk.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: finish crypto callback cleanup before peer release<br /> <br /> Crypto completion callbacks hold both key-slot and peer references. The<br /> peer reference pins the netdev, and dropping the last peer reference can<br /> let netdev unregistration and module removal make progress.<br /> <br /> Do not release that peer reference before the callback has finished its<br /> own cleanup. If ovpn_crypto_key_slot_put runs after ovpn_peer_put, it can<br /> schedule an RCU callback backed by module text after ovpn_cleanup<br /> rcu_barrier has already run. The TX error path also freed the remaining<br /> skb after ovpn_peer_put, leaving callback cleanup outside the peer/netdev<br /> lifetime window.<br /> <br /> Release the key slot and free any remaining skb first, then drop the peer<br /> reference as the last callback action.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: fix NULL dereference when killing missing key<br /> <br /> ovpn_crypto_kill_key assumes both crypto slots are populated and<br /> dereferences each slot before checking it. That is not guaranteed: a<br /> peer can have only one installed key, and the kill path may be asked to<br /> remove a key that is not present.<br /> <br /> Read each slot once while holding the crypto state lock, check for NULL<br /> before looking at key_id, and only replace the slot that actually<br /> matches.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Unlink scc_entry in unix_del_edge().<br /> <br /> Kyle Zeng reported that GC could free a dead SCC partially.<br /> <br /> The scenario is as follows:<br /> <br /> 1) Create two SCCs:<br /> <br /> X -. A B<br /> ^--&amp;#39;<br /> <br /> 2) Run the following concurrently:<br /> <br /> 2-1) send() sk-B to sk-B from sk-X<br /> 2-2) close() both A and B<br /> <br /> At 2-1), there is a small window where unix_add_edges()<br /> publishes a new edge (B B) to GC but its skb is not queued<br /> by skb_queue_tail().<br /> <br /> If 2-2) completes before skb_queue_tail() and GC is triggered,<br /> it judges A B as dead, but B is not freed because GC cannot<br /> collect the not-yet-queued skb holding the B B edge.<br /> <br /> X -. A B -. This edge is visible<br /> ^--&amp;#39; ^..&amp;#39; but skb is not<br /> <br /> This itself is not a problem since the next GC run will judge<br /> B as dead as well and free it finally.<br /> <br /> X -. A B -.<br /> ^--&amp;#39; ^--&amp;#39;<br /> <br /> However, X&amp;#39;s SCC forces the next GC to call unix_walk_scc_fast(),<br /> and it iterates over A through B&amp;#39;s scc_entry.<br /> <br /> Let&amp;#39;s unlink scc_entry before freeing the vertex in unix_del_edge().