Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/filemap: __filemap_add_folio() restore index before retrying<br /> <br /> In __filemap_add_folio()&amp;#39;s split-a-conflict loop, xas_set_order() is<br /> applied repeatedly: each application modifies xas.xa_index, rounding it<br /> down according to the split_order attempted at that stage: and if all goes<br /> as intended, it eventually (or immediately) converges on an<br /> xas_try_split() to the required folio_order, with xas.xa_index now the<br /> same as index: then xas_store() puts the new folio into the xarray there.<br /> <br /> But if a new node was needed, and GFP_NOWAIT allocation did not get one,<br /> the lock is dropped, xas_nomem() used to allocate, and sequence retried. <br /> If (that part of) the xarray is unchanged when the lock is reacquired, no<br /> problem. But what if the conflict was meanwhile resolved by another<br /> thread (perhaps even doing the same thing, inserting a folio at that same<br /> index)? Isn&amp;#39;t there a danger of now putting our folio into the xarray at<br /> an intermediate rounded-down index? With !folio_contains() bug to follow,<br /> when CONFIG_DEBUG_VM=y is checking for that.<br /> <br /> Fix this with an xas_set_order() to restore the original xas.xa_index at<br /> the bottom of the loop, so the retry does a full re-evaluation after<br /> reacquiring the lock, and cannot reach xas_store() with the wrong index.<br /> <br /> Production was suffering from rare SIGILLs and SIGSEGVs, executable text<br /> found a page away from where it belonged, !folio_contains() bug hit when<br /> debug enabled: symptoms not seen since this patch went in.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: Instantiate file_truncate and path_truncate hooks<br /> <br /> Instantiate the file_truncate and path_truncate LSM hooks to reset the<br /> action cache flags (IMA_DONE_MASK) as soon as truncation is requested,<br /> so the file, based on policy, is re-collected, re-measured, re-audited,<br /> and re-appraised on next access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Take cgroup_lock() first in scx_cgroup_lock()<br /> <br /> scx_cgroup_lock() write-locks scx_cgroup_ops_rwsem and then takes<br /> cgroup_lock(), which can deadlock through kernfs:<br /> <br /> scx enable/disable cgroup rmdir cpu.weight write<br /> ------------------ ------------ ----------------<br /> cgroup_lock()<br /> percpu_down_write(rwsem)<br /> cgroup_lock()<br /> kernfs_get_active()<br /> percpu_down_read(rwsem)<br /> kernfs_drain()<br /> <br /> The enable path waits for the rmdir to release cgroup_mutex. The rmdir,<br /> deactivating the cpu controller&amp;#39;s files, waits in kernfs_drain() for the<br /> write&amp;#39;s active reference. The write, in scx_group_set_weight(), waits for<br /> the rwsem behind the pending writer.<br /> <br /> Take cgroup_lock() first. The set_* paths take no cgroup locks inside the<br /> read side, so a pending write-lock then only waits for read sections that<br /> always run to completion, and no dependency from the rwsem back to<br /> cgroup_mutex remains.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: Shut down rtpoll_timer in psi_cgroup_free()<br /> <br /> psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath<br /> and can race psi_trigger_destroy() taking down the last rtpoll trigger under<br /> rtpoll_trigger_lock:<br /> <br /> psi_schedule_rtpoll_work() psi_trigger_destroy()<br /> <br /> rcu_read_lock();<br /> task = rcu_dereference(rtpoll_task);<br /> rcu_assign_pointer(rtpoll_task, NULL);<br /> timer_delete(&amp;rtpoll_timer);<br /> mod_timer(&amp;rtpoll_timer, ...);<br /> rcu_read_unlock();<br /> synchronize_rcu();<br /> kthread_stop(task_to_destroy);<br /> <br /> The group can then be freed with the re-armed timer still pending, and<br /> poll_timer_fn() runs on freed memory.<br /> <br /> 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling<br /> mechanism") deleted the timer synchronously after the synchronize_rcu(),<br /> which prevented this but raced trigger creation instead: the deletion could<br /> cancel the timer that a new trigger set armed during the grace period and,<br /> as creation also reinitialized the timer at the time, corrupt it.<br /> 8f91efd870ea ("psi: Fix race between psi_trigger_create/destroy") moved the<br /> initialization into group_init() and the deletion into the locked section,<br /> trading the creation races for the window above.<br /> <br /> Neither placement in the destruction path works. A pending timer firing<br /> while the group is alive is harmless though. poll_timer_fn() just wakes the<br /> rtpoll waitqueue and doesn&amp;#39;t re-arm itself. Bind the timer to the group&amp;#39;s<br /> lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it<br /> by then. timer_shutdown_sync() because the timer is never armed again.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()<br /> <br /> fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with<br /> &amp;nop_mnt_idmap before allowing an encryption policy to be set, instead<br /> of the idmap of the mount the ioctl was issued on.<br /> <br /> fscrypt is used by filesystems that support idmapped mounts (e.g. ext4,<br /> f2fs), so on such a mount this compares the caller&amp;#39;s fsuid against the<br /> unmapped on-disk owner rather than the mapped owner: the actual owner<br /> can be wrongly denied with -EACCES and an unrelated caller wrongly<br /> allowed. Use file_mnt_idmap(filp) instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs,fsverity: remove check for fsverity being enabled in setattr_prepare()<br /> <br /> The check that fs-verity is available in the kernel is not necessary<br /> here. Filesystems could have fsverity files even without fs-verity<br /> enabled. In that case, truncate on fsverity file will succeed, what this<br /> check is trying to prevent.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Bound the DROM dual link port number before indexing sw-&gt;ports<br /> <br /> tb_drom_parse_entry_port() validates the device-supplied header-&gt;index<br /> against sw-&gt;config.max_port_number before indexing sw-&gt;ports[], but the<br /> sibling field entry-&gt;dual_link_port_nr -- a 6-bit value also read from<br /> the DROM -- indexes the same array with no such check. A malicious or<br /> malformed Thunderbolt device can set dual_link_port_nr beyond the<br /> allocated sw-&gt;ports[] (max_port_number + 1 entries), producing an<br /> out-of-bounds tb_port pointer that is stored and later dereferenced.<br /> <br /> Reject a port entry whose dual_link_port_nr exceeds max_port_number,<br /> the same bound already applied to header-&gt;index.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: clear new_transport when removing a peer<br /> <br /> sctp_process_asconf_param() stores a newly added peer transport in<br /> asoc-&gt;new_transport. After all parameters in the ASCONF chunk have been<br /> processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the<br /> new transport.<br /> <br /> An authenticated ASCONF from a remote SCTP peer can add a transport and<br /> remove it again with a wildcard DEL-IP parameter in the same chunk. The<br /> wildcard deletion preserves the transport on which the ASCONF arrived, but<br /> removes the newly added transport through<br /> sctp_assoc_del_nonprimary_peers(). The removal does not clear<br /> asoc-&gt;new_transport, leaving it pointing to the removed transport.<br /> <br /> sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk-&gt;transport points<br /> to the removed transport without holding a transport reference. During<br /> local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on<br /> control_chunk_list. After the transport is freed by RCU, a successful<br /> ASCONF_ACK for the replacement address releases the queued HEARTBEAT and<br /> sctp_outq_select_transport() reads the freed transport&amp;#39;s state.<br /> <br /> The issue was found during a static audit of SCTP objects. With an<br /> authenticated peer, the reproducer triggered the same KASAN report in 2<br /> of 2 unpatched runs on a KASAN-enabled netdev/main kernel:<br /> <br /> BUG: KASAN: slab-use-after-free in sctp_outq_select_transport<br /> Read of size 4 at addr ffff88800b9bd95c by task python3/197<br /> <br /> Call Trace:<br /> sctp_outq_select_transport+0x549/0x8b0 [sctp]<br /> sctp_outq_flush+0x306/0x2c60 [sctp]<br /> sctp_transport_immediate_rtx+0xaf/0x260 [sctp]<br /> sctp_process_asconf_ack+0xa48/0xf70 [sctp]<br /> <br /> Allocated by task 197:<br /> sctp_transport_new+0x68/0x650 [sctp]<br /> sctp_assoc_add_peer+0x258/0x12a0 [sctp]<br /> sctp_process_asconf+0x5e9/0x1090 [sctp]<br /> <br /> Last potentially related work creation:<br /> __call_rcu_common.constprop.0+0x77/0xb70<br /> sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp]<br /> sctp_process_asconf+0xd9c/0x1090 [sctp]<br /> <br /> The first invalid access was a four-byte read of transport-&gt;state at<br /> net/sctp/outqueue.c:833. The same reproducer completed the full<br /> authenticated ASCONF and local-address replacement sequence with this<br /> change without a KASAN report or oops.<br /> <br /> Clear new_transport when its peer is removed, before it can be used to<br /> create the HEARTBEAT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix use-after-free of cached ASCONF chunk<br /> <br /> addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal<br /> ASCONF-ACK completion path releases the chunk and clears the pointer.<br /> <br /> However, sctp_asconf_queue_teardown() releases the cached chunk without<br /> clearing addip_last_asconf. During peer restart handling,<br /> sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes<br /> sctp_asconf_queue_teardown() while the association remains alive and leaves<br /> the pointer dangling.<br /> <br /> A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(),<br /> which accesses the stale chunk and passes it to sctp_process_asconf_ack(),<br /> causing a use-after-free and a second release.<br /> <br /> Clearing the pointer exposes a race with T4 expiry. Peer restart handling<br /> queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses<br /> timer_delete(), which does not wait for a callback already running on<br /> another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after<br /> the purge and dereference NULL.<br /> <br /> Clear addip_last_asconf after releasing the cached chunk, and make<br /> sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding<br /> ASCONF remains.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: keep chunk-&gt;transport in step with the list it is queued on<br /> <br /> __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport&amp;#39;s<br /> transmitted list without updating chunk-&gt;transport:<br /> <br /> if (chunk-&gt;tsn_gap_acked) {<br /> list_move_tail(&amp;chunk-&gt;transmitted_list,<br /> &amp;transport-&gt;transmitted);<br /> continue;<br /> }<br /> <br /> The chunk then sits on a live transport&amp;#39;s list while chunk-&gt;transport still<br /> names a different one. If that transport is removed - sctp_assoc_rm_peer()<br /> from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk<br /> is left with a dangling pointer. sctp_assoc_rm_peer() scrubs<br /> peer-&gt;transmitted and asoc-&gt;outqueue.out_chunk_list, but the chunk is on<br /> neither.<br /> <br /> The pointer is not followed while tsn_gap_acked is set. A SACK that<br /> reneges on the TSN clears the flag, and the next SACK reaches<br /> <br /> tchunk-&gt;transport-&gt;flight_size -= sctp_data_size(tchunk);<br /> <br /> inside the freed transport. KASAN reports a slab-use-after-free read in<br /> sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the<br /> removal and the SACKs come from the association peer.<br /> <br /> Set chunk-&gt;transport at the move. The ordinary resend path needs nothing:<br /> it reaches its list_move_tail() only after sctp_packet_append_chunk()<br /> returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the<br /> chunk by then.<br /> <br /> Discovered by XBOW, triaged by Baul Lee

*** Pendiente de traducción *** The WS Form LITE – Drag &amp; Drop Contact Form Builder plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 1.10.80 via deserialization of untrusted input from form submission meta values. This makes it possible for unauthenticated attackers to inject a PHP Object. No known POP chain is present in the vulnerable software, which means this vulnerability has no impact unless another plugin or theme containing a POP chain is installed on the site. If a POP chain is present via an additional plugin or theme installed on the target system, it may allow the attacker to perform actions like delete arbitrary files, retrieve sensitive data, or execute code depending on the POP chain present.

*** Pendiente de traducción *** Joomla Extension - fabrikar.com - Unauthenticated modification of any comment in Fabrik