Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/iommufd: Fix IOPF group ownership UAF<br /> <br /> iopf_group_alloc() links each last-page IOPF group into the generic IOPF<br /> pending list before invoking the domain fault handler.<br /> iommufd_fault_iopf_handler() also queued an accepted group in the<br /> IOMMUFD deliver list without removing it from the generic pending list.<br /> <br /> When detach or HWPT replacement drops the device&amp;#39;s IOPF reference count<br /> to zero, an IOMMU driver may call iopf_queue_remove_device(). That<br /> function responds to and frees groups through the generic pending list<br /> without removing the same groups from IOMMUFD&amp;#39;s deliver list or response<br /> xarray. A later read, response, or cleanup can then access the freed<br /> group and cause a UAF.<br /> <br /> Fix this by dequeuing an accepted group from the generic pending list<br /> before IOMMUFD queues it for userspace response.<br /> Make iopf_group_response() send a response regardless of pending-list<br /> membership, so the dequeued group can still be completed by IOMMUFD.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: use memcmp() to compare ClientGUIDs<br /> <br /> ClientGUID is a fixed-size binary value and can contain embedded NUL<br /> bytes. strncmp() stops comparing at the first NUL byte, so different<br /> ClientGUID values can incorrectly be treated as equal.<br /> <br /> Use memcmp() in SMB3 multichannel session binding and<br /> FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE<br /> bytes.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in __close_file_table_ids()<br /> <br /> A ksmbd_file can remain alive after logical close while another session<br /> holds a temporary reference obtained through ksmbd_lookup_fd_inode().<br /> ksmbd_close_fd() currently marks the file closed and drops the idr-owned<br /> reference, but leaves the pointer published in the closing session&amp;#39;s idr<br /> until the final reference is dropped.<br /> <br /> If the foreign holder performs the final ksmbd_fd_put(), __put_fd_final()<br /> supplies the foreign session&amp;#39;s file table to __ksmbd_close_fd(). The object<br /> is then freed without being removed from its owner&amp;#39;s idr, and the owner<br /> session later dereferences the stale pointer during file-table teardown.<br /> <br /> Remove the volatile id from the owner&amp;#39;s idr while ksmbd_close_fd() still<br /> holds that table&amp;#39;s lock, and clear volatile_id before dropping<br /> the idr-owned reference. A later foreign final put then only performs<br /> physical destruction and cannot remove the object from the wrong table.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qede: sync udp_tunnel ports outside qede_lock in the recovery path<br /> <br /> A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports<br /> configured wedges the rtnetlink control plane of the whole machine:<br /> <br /> NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms<br /> [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2!<br /> [qede_recovery_handler:2665(ens6f0)]Starting a recovery process<br /> <br /> The recovery path deadlocks on the driver&amp;#39;s own mutex:<br /> <br /> qede_sp_task<br /> rtnl_lock()<br /> mutex_lock(&amp;edev-&gt;qede_lock) sync_table == qede_udp_tunnel_sync<br /> mutex_lock(&amp;edev-&gt;qede_lock)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove<br /> <br /> remove_pud_mapping() and remove_p4d_mapping() obtain a child table base<br /> with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for<br /> addr.<br /> <br /> RISC-V folds page-table levels at runtime. When a level is folded, its<br /> offset helper returns the parent entry itself, but the index can still be<br /> nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39<br /> folds both P4D and PUD, so memory hot-remove can descend into unrelated<br /> memory and pass an invalid page to __free_pages(). This can trigger:<br /> <br /> kernel BUG at include/linux/mm.h:1810!<br /> VM_BUG_ON_PAGE(page_ref_count(page) == 0)<br /> arch_remove_memory+0x1e/0x5c<br /> try_remove_memory+0x15e/0x200<br /> remove_memory+0x24/0x3c<br /> <br /> Only add the index when the corresponding page-table level is enabled,<br /> matching p4d_offset() and pud_offset().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sxgbe: free TX rings on RX allocation failure<br /> <br /> When RX descriptor ring allocation fails, init_dma_desc_rings() only<br /> frees the partially allocated RX rings and returns. The TX rings that<br /> were allocated earlier in the same function are leaked.<br /> <br /> Rearrange error labels to clean up TX rings upon RX failures.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit<br /> <br /> mpi3mr_fault_uevent_emit() runs from the fault watchdog and reset paths<br /> where host I/O may already be blocked. GFP_KERNEL allocations here, both<br /> the local kzalloc_obj() and the ones inside kobject_uevent_env() itself,<br /> can trigger reclaim that waits on that blocked I/O and deadlock.<br /> <br /> Use memalloc_noio_save()/restore() to cover the whole call instead of<br /> just the local allocation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Block VFs from clobbering special CGX PKIND state<br /> <br /> PF and VF NIX LFs that share a CGX LMAC reuse the same hardware PKIND<br /> programming. When HiGig2 or EDSA parsing is enabled, a VF NIX LF alloc must<br /> not reset the LMAC RX PKIND or default TX parse config over the PF setup.<br /> <br /> Add cgx_get_pkind() and rvu_cgx_is_pkind_config_permitted() so VFs skip<br /> cgx_set_pkind(), rvu_npc_set_pkind(), and NIX_AF_LFX_TX_PARSE_CFG updates<br /> when the LMAC is using NPC_RX_HIGIG_PKIND or NPC_RX_EDSA_PKIND.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: mgmt: fix UAF in pair command cancellation<br /> <br /> The pairing completion and authentication failure callbacks look up the<br /> pending MGMT_OP_PAIR_DEVICE command by walking hdev-&gt;mgmt_pending. The<br /> lookup returned a command that was still linked on the shared pending list,<br /> without keeping mgmt_pending_lock held for the later dereference and<br /> removal.<br /> <br /> A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the<br /> same pending command before the callback uses it. The reverse race is also<br /> possible when cancel_pair_device() gets a command from pending_find() and a<br /> callback removes it before the cancel path dereferences it. This can lead<br /> to a use-after-free and a second list_del().<br /> <br /> Make the pairing lookup helpers transfer ownership of the pending command<br /> by removing it from hdev-&gt;mgmt_pending while holding mgmt_pending_lock.<br /> The callbacks and cancel path then complete the command and free it<br /> directly, so racing paths cannot find or free the same command again. Take<br /> a temporary hci_conn reference in cancel_pair_device() because the command<br /> completion drops the reference stored in the pending command.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: mgmt: fix pending command UAF in EIR updates<br /> <br /> MGMT_OP_SET_LOCAL_NAME is handled asynchronously on powered controllers<br /> and can run set_name_sync(). When the controller is BR/EDR capable,<br /> set_name_sync() updates the local name and then rebuilds EIR data through<br /> eir_create(). The EIR builder walks hdev-&gt;uuids, but the UUID list can<br /> be changed and entries can be freed by MGMT_OP_ADD_UUID and<br /> MGMT_OP_REMOVE_UUID.<br /> <br /> pending_eir_or_class() is meant to serialize management commands that<br /> can change EIR or the class of device, but it did not include<br /> MGMT_OP_SET_LOCAL_NAME. In addition, it walked hdev-&gt;mgmt_pending<br /> without hdev-&gt;mgmt_pending_lock even though pending commands are added<br /> and removed under that mutex. A racing command completion can therefore<br /> remove and free a pending command while pending_eir_or_class() is still<br /> inspecting it, leading to a use-after-free in the pending-command list or<br /> allowing a local name update to rebuild EIR while UUID entries are being<br /> removed.<br /> <br /> Take hdev-&gt;mgmt_pending_lock while scanning hdev-&gt;mgmt_pending and treat<br /> MGMT_OP_SET_LOCAL_NAME as an EIR/class-affecting pending command on the<br /> powered asynchronous path. Check for a conflicting pending command before<br /> copying the new short name so a rejected SET_LOCAL_NAME request does not<br /> modify hdev-&gt;short_name.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: fix potential use-after-free in audit_del_rule()<br /> <br /> `audit_del_rule()` destroys `e-&gt;rule.exe` via `audit_remove_mark_rule()`<br /> before unlinking the rule from RCU-visible filter lists and waiting for a<br /> grace period. Concurrent readers in `audit_filter()` and<br /> `audit_filter_rules()` still dereference `e-&gt;rule.exe`, while the fsnotify<br /> mark can be freed on an independent lifetime path. This creates a<br /> use-after-free window during rule deletion.<br /> <br /> Fix this by unlinking the rule from the RCU-visible lists and invoking<br /> `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other<br /> rule removal helpers). This ensures that all existing RCU readers have<br /> exited the critical section before any underlying resources are destroyed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister<br /> <br /> dibs_lo_attach_dmb(), dibs_lo_detach_dmb() and dibs_lo_unregister_dmb()<br /> look up the dmb_node under dmb_ht_lock, drop the lock and only then<br /> operate on the node&amp;#39;s refcount. Nothing keeps the node alive across<br /> that window: __dibs_lo_unregister_dmb() removes the node from the hash<br /> table under the write lock and immediately frees it.<br /> <br /> A concurrent final put can therefore free the node between the lookup<br /> and the refcount operation:<br /> <br /> CPU0 (attach) CPU1 (owner unregisters)<br /> <br /> read_lock_bh(&amp;dmb_ht_lock)<br /> find dmb_node (refcnt == 1)<br /> read_unlock_bh(&amp;dmb_ht_lock)<br /> refcount_dec_and_test() 1 -&gt; 0<br /> write_lock_bh(&amp;dmb_ht_lock)<br /> hash_del(&amp;dmb_node-&gt;list)<br /> write_unlock_bh(&amp;dmb_ht_lock)<br /> kfree(dmb_node)<br /> refcount_inc_not_zero(&amp;dmb_node-&gt;refcnt)