Vulnerabilities

A flaw was found in 389 Directory Server. A type confusion in the SSO token extended operation handler causes partial stack address information to be disclosed in LDAP responses to authenticated users.

A flaw was found in 389 Directory Server. The LDIF parser reads past the end of a heap buffer when processing attribute types with trailing semicolons during database import, causing an out-of-bounds read detectable under memory instrumentation.

A flaw was found in 389 Directory Server. The ldap_utf8prev() function reads bytes before the start of a buffer without bounds checking, causing a heap buffer over-read in string filter parsing that may influence internal filter processing behavior.

A flaw was found in 389 Directory Server. The dereference control plugin does not check for allocation failure before using a BER structure, allowing an unauthenticated remote attacker to crash the LDAP server when the system is under memory pressure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Reassign nested_mmus array behind mmu_lock<br /> <br /> kvm-&gt;arch.nested_mmus[] is walked under kvm-&gt;mmu_lock, including from the<br /> MMU notifier path (kvm_unmap_gfn_range() -&gt; kvm_nested_s2_unmap()), which<br /> can run at any time. kvm_vcpu_init_nested() reallocates the array and frees<br /> the old buffer while holding only kvm-&gt;arch.config_lock, so such a walker<br /> can reference the freed array.<br /> <br /> Allocate the new array outside of mmu_lock, as the allocation can sleep.<br /> Under the lock, copy the existing entries, fix up the back pointers and<br /> reassign the array. Free the old buffer after dropping the lock, as<br /> kvfree() can sleep as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare"<br /> <br /> This reverts commit ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use<br /> mmap_prepare") with conflict resolution to account for changes in commit<br /> ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare").<br /> <br /> The patch incorrectly handled hugetlb VMA lock allocation at the<br /> mmap_prepare stage, where a failed allocation occurring after mmap_prepare<br /> is called might result in the lock leaking.<br /> <br /> There is no risk of a merge causing a similar issues, as<br /> VMA_DONTEXPAND_BIT is set for hugetlb mappings.<br /> <br /> As a first step in addressing this issue, simply revert the change so we<br /> can rework how we do this having corrected the underlying issues.<br /> <br /> We maintain the VMA flags changes as best we can, accounting for the fact<br /> that we were working with a VMA descriptor previously and propagating<br /> like-for-like changes for this.<br /> <br /> Note that we invoke vma_set_flags() and do not call vma_start_write() as<br /> vm_flags_set() does. This is OK as it&amp;#39;s being done in an .mmap hook where<br /> the VMA is not yet linked into the tree so nobody else can be accessing<br /> it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ct: Only release RCU read lock after ct_ft<br /> <br /> When looking up a flow table in act_ct in tcf_ct_flow_table_get(),<br /> rhashtable_lookup_fast() internally opens and closes an RCU read critical<br /> section before returning ct_ft.<br /> The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero()<br /> is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft<br /> object. This vulnerability can lead to privilege escalation.<br /> <br /> Analysis from zdi-disclosures@trendmicro.com:<br /> When initializing act_ct, tcf_ct_init() is called, which internally triggers<br /> tcf_ct_flow_table_get().<br /> <br /> static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params)<br /> <br /> {<br /> struct zones_ht_key key = { .net = net, .zone = params-&gt;zone };<br /> struct tcf_ct_flow_table *ct_ft;<br /> int err = -ENOMEM;<br /> <br /> mutex_lock(&amp;zones_mutex);<br /> ct_ft = rhashtable_lookup_fast(&amp;zones_ht, &amp;key, zones_params); // [1]<br /> if (ct_ft &amp;&amp; refcount_inc_not_zero(&amp;ct_ft-&gt;ref)) // [2]<br /> goto out_unlock;<br /> ...<br /> }<br /> <br /> static __always_inline void *rhashtable_lookup_fast(<br /> struct rhashtable *ht, const void *key,<br /> const struct rhashtable_params params)<br /> {<br /> void *obj;<br /> <br /> rcu_read_lock();<br /> obj = rhashtable_lookup(ht, key, params);<br /> rcu_read_unlock();<br /> <br /> return obj;<br /> }<br /> <br /> At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft<br /> from zones_ht . The lookup is performed within an RCU read critical section<br /> through rcu_read_lock() / rcu_read_unlock(), which prevents the object from<br /> being freed. However, at the point of function return, rcu_read_unlock() has<br /> already been called, and there is nothing preventing ct_ft from being freed<br /> before reaching refcount_inc_not_zero(&amp;ct_ft-&gt;ref) at [2]. This interval becomes<br /> the race window, during which ct_ft can be freed.<br /> <br /> Free Process:<br /> <br /> tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu()<br /> tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put().<br /> <br /> static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft)<br /> {<br /> if (refcount_dec_and_test(&amp;ct_ft-&gt;ref)) {<br /> rhashtable_remove_fast(&amp;zones_ht, &amp;ct_ft-&gt;node, zones_params);<br /> INIT_RCU_WORK(&amp;ct_ft-&gt;rwork, tcf_ct_flow_table_cleanup_work); // [3]<br /> queue_rcu_work(act_ct_wq, &amp;ct_ft-&gt;rwork);<br /> }<br /> }<br /> <br /> At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work<br /> <br /> static void tcf_ct_flow_table_cleanup_work(struct work_struct *work)<br /> <br /> {<br /> struct tcf_ct_flow_table *ct_ft;<br /> struct flow_block *block;<br /> <br /> ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table,<br /> rwork);<br /> nf_flow_table_free(&amp;ct_ft-&gt;nf_ft);<br /> block = &amp;ct_ft-&gt;nf_ft.flow_block;<br /> down_write(&amp;ct_ft-&gt;nf_ft.flow_block_lock);<br /> WARN_ON(!list_empty(&amp;block-&gt;cb_list));<br /> up_write(&amp;ct_ft-&gt;nf_ft.flow_block_lock);<br /> kfree(ct_ft); // [4]<br /> <br /> module_put(THIS_MODULE);<br /> }<br /> <br /> tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes<br /> between [1] and [2], UAF occurs.<br /> <br /> This race condition has a very short race window, making it generally<br /> difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was<br /> inserted after[1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tap: free page on error paths in tap_get_user_xdp()<br /> <br /> tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,<br /> and returns -ENOMEM when build_skb() fails. Both paths jump to the err<br /> label without freeing the page that vhost_net_build_xdp() allocated for<br /> the frame. tap_sendmsg() discards the per-buffer return value and always<br /> returns 0, so vhost_tx_batch() takes the success path and never frees<br /> the page; each rejected frame in a batch leaks one page-frag chunk.<br /> <br /> Free the page on both error paths, before the skb is built. This is the<br /> tap counterpart of the same leak in tun_xdp_one().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tun: free page on short-frame rejection in tun_xdp_one()<br /> <br /> tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without<br /> freeing the page that vhost_net_build_xdp() allocated for it.<br /> tun_sendmsg() discards that -EINVAL and still returns total_len, so<br /> vhost_tx_batch() takes the success path and never frees the page; each<br /> short frame in a batch leaks one page-frag chunk.<br /> <br /> A local process that can open /dev/net/tun and /dev/vhost-net can hit<br /> this path: it attaches a tun/tap device as the vhost-net backend and<br /> feeds TX descriptors whose length minus the virtio-net header is below<br /> ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a<br /> tight submission loop exhausts host memory and triggers an OOM panic.<br /> Free the page before returning -EINVAL, matching the XDP-program error<br /> path in the same function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tun: free page on build_skb failure in tun_xdp_one()<br /> <br /> When build_skb() fails in tun_xdp_one(), the function sets ret to<br /> -ENOMEM and jumps to the out label, which returns without freeing the<br /> page that vhost_net_build_xdp() allocated for the frame. As with the<br /> short-frame rejection path, tun_sendmsg() discards the per-buffer error<br /> and still returns total_len, so vhost_tx_batch() takes the success path<br /> and never frees the page. Each build_skb() failure in a batch leaks one<br /> page-frag chunk.<br /> <br /> Free the page before taking the error path, matching the put_page() the<br /> other error exits of tun_xdp_one() already perform.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: use list_del_rcu for netlink hooks<br /> <br /> nft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks need<br /> to use list_del_rcu(), this list can be walked by concurrent dumpers.<br /> <br /> Add a new helper and use it consistently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gro: don&amp;#39;t merge zcopy skbs<br /> <br /> skb_gro_receive() can currently copy frags between the source and GRO<br /> skb, without checking the zerocopy status, and in particular the<br /> SKBFL_MANAGED_FRAG_REFS flag.<br /> <br /> When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn&amp;#39;t hold a reference<br /> on the pages in shinfo-&gt;frags. Appending those frags to another skb&amp;#39;s<br /> frags without fixing up the page refcount can lead to UAF.<br /> <br /> When either the last skb in the GRO chain (the one we would append<br /> frags to) or the source skb is zerocopy, don&amp;#39;t merge the skbs.