Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix zero size inode with non-zero size after log replay<br /> <br /> When logging that an inode exists, as part of logging a new name or<br /> logging new dir entries for a directory, we always set the generation of<br /> the logged inode item to 0. This is to signal during log replay (in<br /> overwrite_item()), that we should not set the i_size since we only logged<br /> that an inode exists, so the i_size of the inode in the subvolume tree<br /> must be preserved (as when we log new names or that an inode exists, we<br /> don&amp;#39;t log extents).<br /> <br /> This works fine except when we have already logged an inode in full mode<br /> or it&amp;#39;s the first time we are logging an inode created in a past<br /> transaction, that inode has a new i_size of 0 and then we log a new name<br /> for the inode (due to a new hardlink or a rename), in which case we log<br /> an i_size of 0 for the inode and a generation of 0, which causes the log<br /> replay code to not update the inode&amp;#39;s i_size to 0 (in overwrite_item()).<br /> <br /> An example scenario:<br /> <br /> mkdir /mnt/dir<br /> xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo<br /> <br /> sync<br /> <br /> xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo<br /> <br /> ln /mnt/dir/foo /mnt/dir/bar<br /> <br /> xfs_io -c "fsync" /mnt/dir<br /> <br /> <br /> <br /> After log replay the file remains with a size of 64K. This is because when<br /> we first log the inode, when we fsync file foo, we log its current i_size<br /> of 0, and then when we create a hard link we log again the inode in exists<br /> mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we<br /> add to the log tree, so during log replay overwrite_item() sees that the<br /> generation is 0 and i_size is 0 so we skip updating the inode&amp;#39;s i_size<br /> from 64K to 0.<br /> <br /> Fix this by making sure at fill_inode_item() we always log the real<br /> generation of the inode if it was logged in the current transaction with<br /> the i_size we logged before. Also if an inode created in a previous<br /> transaction is logged in exists mode only, make sure we log the i_size<br /> stored in the inode item located from the commit root, so that if we log<br /> multiple times that the inode exists we get the correct i_size.<br /> <br /> A test case for fstests will follow soon.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()<br /> <br /> If overlay is used on top of btrfs, dentry-&gt;d_sb translates to overlay&amp;#39;s<br /> super block and fsid assignment will lead to a crash.<br /> <br /> Use file_inode(file)-&gt;i_sb to always get btrfs_sb.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: ensure safe access to master conntrack<br /> <br /> Holding reference on the expectation is not sufficient, the master<br /> conntrack object can just go away, making exp-&gt;master invalid.<br /> <br /> To access exp-&gt;master safely:<br /> <br /> - Grab the nf_conntrack_expect_lock, this gets serialized with<br /> clean_from_lists() which also holds this lock when the master<br /> conntrack goes away.<br /> <br /> - Hold reference on master conntrack via nf_conntrack_find_get().<br /> Not so easy since the master tuple to look up for the master conntrack<br /> is not available in the existing problematic paths.<br /> <br /> This patch goes for extending the nf_conntrack_expect_lock section<br /> to address this issue for simplicity, in the cases that are described<br /> below this is just slightly extending the lock section.<br /> <br /> The add expectation command already holds a reference to the master<br /> conntrack from ctnetlink_create_expect().<br /> <br /> However, the delete expectation command needs to grab the spinlock<br /> before looking up for the expectation. Expand the existing spinlock<br /> section to address this to cover the expectation lookup. Note that,<br /> the nf_ct_expect_iterate_net() calls already grabs the spinlock while<br /> iterating over the expectation table, which is correct.<br /> <br /> The get expectation command needs to grab the spinlock to ensure master<br /> conntrack does not go away. This also expands the existing spinlock<br /> section to cover the expectation lookup too. I needed to move the<br /> netlink skb allocation out of the spinlock to keep it GFP_KERNEL.<br /> <br /> For the expectation events, the IPEXP_DESTROY event is already delivered<br /> under the spinlock, just move the delivery of IPEXP_NEW under the<br /> spinlock too because the master conntrack event cache is reached through<br /> exp-&gt;master.<br /> <br /> While at it, add lockdep notations to help identify what codepaths need<br /> to grab the spinlock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> srcu: Use irq_work to start GP in tiny SRCU<br /> <br /> Tiny SRCU&amp;#39;s srcu_gp_start_if_needed() directly calls schedule_work(),<br /> which acquires the workqueue pool-&gt;lock.<br /> <br /> This causes a lockdep splat when call_srcu() is called with a scheduler<br /> lock held, due to:<br /> <br /> call_srcu() [holding pi_lock]<br /> srcu_gp_start_if_needed()<br /> schedule_work() -&gt; pool-&gt;lock<br /> <br /> workqueue_init() / create_worker() [holding pool-&gt;lock]<br /> wake_up_process() -&gt; try_to_wake_up() -&gt; pi_lock<br /> <br /> Also add irq_work_sync() to cleanup_srcu_struct() to prevent a<br /> use-after-free if a queued irq_work fires after cleanup begins.<br /> <br /> Tested with rcutorture SRCU-T and no lockdep warnings.<br /> <br /> [ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_work<br /> to start process_srcu()" ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo_avx2: don&amp;#39;t return non-matching entry on expiry<br /> <br /> New test case fails unexpectedly when avx2 matching functions are used.<br /> <br /> The test first loads a ranomly generated pipapo set<br /> with &amp;#39;ipv4 . port&amp;#39; key, i.e. nft -f foo.<br /> <br /> This works. Then, it reloads the set after a flush:<br /> (echo flush set t s; cat foo) | nft -f -<br /> <br /> This is expected to work, because its the same set after all and it was<br /> already loaded once.<br /> <br /> But with avx2, this fails: nft reports a clashing element.<br /> <br /> The reported clash is of following form:<br /> <br /> We successfully re-inserted<br /> a . b<br /> c . d<br /> <br /> Then we try to insert a . d<br /> <br /> avx2 finds the already existing a . d, which (due to &amp;#39;flush set&amp;#39;) is marked<br /> as invalid in the new generation. It skips the element and moves to next.<br /> <br /> Due to incorrect masking, the skip-step finds the next matching<br /> element *only considering the first field*,<br /> <br /> i.e. we return the already reinserted "a . b", even though the<br /> last field is different and the entry should not have been matched.<br /> <br /> No such error is reported for the generic c implementation (no avx2) or when<br /> the last field has to use the &amp;#39;nft_pipapo_avx2_lookup_slow&amp;#39; fallback.<br /> <br /> Bisection points to<br /> 7711f4bb4b36 ("netfilter: nft_set_pipapo: fix range overlap detection")<br /> but that fix merely uncovers this bug.<br /> <br /> Before this commit, the wrong element is returned, but erronously<br /> reported as a full, identical duplicate.<br /> <br /> The root-cause is too early return in the avx2 match functions.<br /> When we process the last field, we should continue to process data<br /> until the entire input size has been consumed to make sure no stale<br /> bits remain in the map.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wl1251: validate packet IDs before indexing tx_frames<br /> <br /> wl1251_tx_packet_cb() uses the firmware completion ID directly to index<br /> the fixed 16-entry wl-&gt;tx_frames[] array. The ID is a raw u8 from the<br /> completion block, and the callback does not currently verify that it<br /> fits the array before dereferencing it.<br /> <br /> Reject completion IDs that fall outside wl-&gt;tx_frames[] and keep the<br /> existing NULL check in the same guard. This keeps the fix local to the<br /> trust boundary and avoids touching the rest of the completion flow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: annotate data-races around hdev-&gt;req_status<br /> <br /> __hci_cmd_sync_sk() sets hdev-&gt;req_status under hdev-&gt;req_lock:<br /> <br /> hdev-&gt;req_status = HCI_REQ_PEND;<br /> <br /> However, several other functions read or write hdev-&gt;req_status without<br /> holding any lock:<br /> <br /> - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)<br /> - hci_cmd_sync_complete() reads/writes from HCI event completion<br /> - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write<br /> - hci_abort_conn() reads in connection abort path<br /> <br /> Since __hci_cmd_sync_sk() runs on hdev-&gt;req_workqueue while<br /> hci_send_cmd_sync() runs on hdev-&gt;workqueue, these are different<br /> workqueues that can execute concurrently on different CPUs. The plain<br /> C accesses constitute a data race.<br /> <br /> Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses<br /> to hdev-&gt;req_status to prevent potential compiler optimizations that<br /> could affect correctness (e.g., load fusing in the wait_event<br /> condition or store reordering).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix double free related to rereg_user_mr<br /> <br /> If IB_MR_REREG_TRANS is set during rereg_user_mr, the<br /> umem will be released and a new one will be allocated<br /> in irdma_rereg_mr_trans. If any step of irdma_rereg_mr_trans<br /> fails after the new umem is allocated, it releases the umem,<br /> but does not set iwmr-&gt;region to NULL. The problem is that<br /> this failure is propagated to the user, who will then call<br /> ibv_dereg_mr (as they should). Then, the dereg_mr path will<br /> see a non-NULL umem and attempt to call ib_umem_release again.<br /> <br /> Fix this by setting iwmr-&gt;region to NULL after ib_umem_release.<br /> <br /> Fixed: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath<br /> <br /> When cifs_sanitize_prepath is called with an empty string or a string<br /> containing only delimiters (e.g., "/"), the current logic attempts to<br /> check *(cursor2 - 1) before cursor2 has advanced. This results in an<br /> out-of-bounds read.<br /> <br /> This patch adds an early exit check after stripping prepended<br /> delimiters. If no path content remains, the function returns NULL.<br /> <br /> The bug was identified via manual audit and verified using a<br /> standalone test case compiled with AddressSanitizer, which<br /> triggered a SEGV on affected inputs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: roccat: fix use-after-free in roccat_report_event<br /> <br /> roccat_report_event() iterates over the device-&gt;readers list without<br /> holding the readers_lock. This allows a concurrent roccat_release() to<br /> remove and free a reader while it&amp;#39;s still being accessed, leading to a<br /> use-after-free.<br /> <br /> Protect the readers list traversal with the readers_lock mutex.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: validate bsscfg indices in IF events<br /> <br /> brcmf_fweh_handle_if_event() validates the firmware-provided interface<br /> index before it touches drvr-&gt;iflist[], but it still uses the raw<br /> bsscfgidx field as an array index without a matching range check.<br /> <br /> Reject IF events whose bsscfg index does not fit in drvr-&gt;iflist[]<br /> before indexing the interface array.<br /> <br /> [add missing wifi prefix]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_ei<br /> <br /> It looks element length declared in servreg_loc_pfr_req_ei for reason<br /> not matching servreg_loc_pfr_req&amp;#39;s reason field due which we could<br /> observe decoding error on PD crash.<br /> <br /> qmi_decode_string_elem: String len 81 &gt;= Max Len 65<br /> <br /> Fix this by matching with servreg_loc_pfr_req&amp;#39;s reason field.