Vulnerabilities

A privilege escalation exists in the updater for Plantronics Hub 3.25.1 and below.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2<br /> <br /> This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move<br /> on same heap. The basic problem here is that after the move the old<br /> location is simply not available any more.<br /> <br /> Some fixes were suggested, but essentially we should call the move<br /> notification before actually moving things because only this way we have<br /> the correct order for DMA-buf and VM move notifications as well.<br /> <br /> Also rework the statistic handling so that we don&amp;#39;t update the eviction<br /> counter before the move.<br /> <br /> v2: add missing NULL check

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: nosy: ensure user_length is taken into account when fetching packet contents<br /> <br /> Ensure that packet_buffer_get respects the user_length provided. If<br /> the length of the head packet exceeds the user_length, packet_buffer_get<br /> will now return 0 to signify to the user that no data were read<br /> and a larger buffer size is required. Helps prevent user space overflows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout<br /> <br /> When the sco connection is established and then, the sco socket<br /> is releasing, timeout_work will be scheduled to judge whether<br /> the sco disconnection is timeout. The sock will be deallocated<br /> later, but it is dereferenced again in sco_sock_timeout. As a<br /> result, the use-after-free bugs will happen. The root cause is<br /> shown below:<br /> <br /> Cleanup Thread | Worker Thread<br /> sco_sock_release |<br /> sco_sock_close |<br /> __sco_sock_close |<br /> sco_sock_set_timer |<br /> schedule_delayed_work |<br /> sco_sock_kill | (wait a time)<br /> sock_put(sk) //FREE | sco_sock_timeout<br /> | sock_hold(sk) //USE<br /> <br /> The KASAN report triggered by POC is shown below:<br /> <br /> [ 95.890016] ==================================================================<br /> [ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0<br /> [ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7<br /> ...<br /> [ 95.890755] Workqueue: events sco_sock_timeout<br /> [ 95.890755] Call Trace:<br /> [ 95.890755] <br /> [ 95.890755] dump_stack_lvl+0x45/0x110<br /> [ 95.890755] print_address_description+0x78/0x390<br /> [ 95.890755] print_report+0x11b/0x250<br /> [ 95.890755] ? __virt_addr_valid+0xbe/0xf0<br /> [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0<br /> [ 95.890755] kasan_report+0x139/0x170<br /> [ 95.890755] ? update_load_avg+0xe5/0x9f0<br /> [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0<br /> [ 95.890755] kasan_check_range+0x2c3/0x2e0<br /> [ 95.890755] sco_sock_timeout+0x5e/0x1c0<br /> [ 95.890755] process_one_work+0x561/0xc50<br /> [ 95.890755] worker_thread+0xab2/0x13c0<br /> [ 95.890755] ? pr_cont_work+0x490/0x490<br /> [ 95.890755] kthread+0x279/0x300<br /> [ 95.890755] ? pr_cont_work+0x490/0x490<br /> [ 95.890755] ? kthread_blkcg+0xa0/0xa0<br /> [ 95.890755] ret_from_fork+0x34/0x60<br /> [ 95.890755] ? kthread_blkcg+0xa0/0xa0<br /> [ 95.890755] ret_from_fork_asm+0x11/0x20<br /> [ 95.890755] <br /> [ 95.890755]<br /> [ 95.890755] Allocated by task 506:<br /> [ 95.890755] kasan_save_track+0x3f/0x70<br /> [ 95.890755] __kasan_kmalloc+0x86/0x90<br /> [ 95.890755] __kmalloc+0x17f/0x360<br /> [ 95.890755] sk_prot_alloc+0xe1/0x1a0<br /> [ 95.890755] sk_alloc+0x31/0x4e0<br /> [ 95.890755] bt_sock_alloc+0x2b/0x2a0<br /> [ 95.890755] sco_sock_create+0xad/0x320<br /> [ 95.890755] bt_sock_create+0x145/0x320<br /> [ 95.890755] __sock_create+0x2e1/0x650<br /> [ 95.890755] __sys_socket+0xd0/0x280<br /> [ 95.890755] __x64_sys_socket+0x75/0x80<br /> [ 95.890755] do_syscall_64+0xc4/0x1b0<br /> [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 95.890755]<br /> [ 95.890755] Freed by task 506:<br /> [ 95.890755] kasan_save_track+0x3f/0x70<br /> [ 95.890755] kasan_save_free_info+0x40/0x50<br /> [ 95.890755] poison_slab_object+0x118/0x180<br /> [ 95.890755] __kasan_slab_free+0x12/0x30<br /> [ 95.890755] kfree+0xb2/0x240<br /> [ 95.890755] __sk_destruct+0x317/0x410<br /> [ 95.890755] sco_sock_release+0x232/0x280<br /> [ 95.890755] sock_close+0xb2/0x210<br /> [ 95.890755] __fput+0x37f/0x770<br /> [ 95.890755] task_work_run+0x1ae/0x210<br /> [ 95.890755] get_signal+0xe17/0xf70<br /> [ 95.890755] arch_do_signal_or_restart+0x3f/0x520<br /> [ 95.890755] syscall_exit_to_user_mode+0x55/0x120<br /> [ 95.890755] do_syscall_64+0xd1/0x1b0<br /> [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 95.890755]<br /> [ 95.890755] The buggy address belongs to the object at ffff88800c388000<br /> [ 95.890755] which belongs to the cache kmalloc-1k of size 1024<br /> [ 95.890755] The buggy address is located 128 bytes inside of<br /> [ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)<br /> [ 95.890755]<br /> [ 95.890755] The buggy address belongs to the physical page:<br /> [ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388<br /> [ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> [ 95.890755] ano<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout<br /> <br /> There is a race condition between l2cap_chan_timeout() and<br /> l2cap_chan_del(). When we use l2cap_chan_del() to delete the<br /> channel, the chan-&gt;conn will be set to null. But the conn could<br /> be dereferenced again in the mutex_lock() of l2cap_chan_timeout().<br /> As a result the null pointer dereference bug will happen. The<br /> KASAN report triggered by POC is shown below:<br /> <br /> [ 472.074580] ==================================================================<br /> [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0<br /> [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7<br /> [ 472.075308]<br /> [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36<br /> [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4<br /> [ 472.075308] Workqueue: events l2cap_chan_timeout<br /> [ 472.075308] Call Trace:<br /> [ 472.075308] <br /> [ 472.075308] dump_stack_lvl+0x137/0x1a0<br /> [ 472.075308] print_report+0x101/0x250<br /> [ 472.075308] ? __virt_addr_valid+0x77/0x160<br /> [ 472.075308] ? mutex_lock+0x68/0xc0<br /> [ 472.075308] kasan_report+0x139/0x170<br /> [ 472.075308] ? mutex_lock+0x68/0xc0<br /> [ 472.075308] kasan_check_range+0x2c3/0x2e0<br /> [ 472.075308] mutex_lock+0x68/0xc0<br /> [ 472.075308] l2cap_chan_timeout+0x181/0x300<br /> [ 472.075308] process_one_work+0x5d2/0xe00<br /> [ 472.075308] worker_thread+0xe1d/0x1660<br /> [ 472.075308] ? pr_cont_work+0x5e0/0x5e0<br /> [ 472.075308] kthread+0x2b7/0x350<br /> [ 472.075308] ? pr_cont_work+0x5e0/0x5e0<br /> [ 472.075308] ? kthread_blkcg+0xd0/0xd0<br /> [ 472.075308] ret_from_fork+0x4d/0x80<br /> [ 472.075308] ? kthread_blkcg+0xd0/0xd0<br /> [ 472.075308] ret_from_fork_asm+0x11/0x20<br /> [ 472.075308] <br /> [ 472.075308] ==================================================================<br /> [ 472.094860] Disabling lock debugging due to kernel taint<br /> [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158<br /> [ 472.096136] #PF: supervisor write access in kernel mode<br /> [ 472.096136] #PF: error_code(0x0002) - not-present page<br /> [ 472.096136] PGD 0 P4D 0<br /> [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36<br /> [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4<br /> [ 472.096136] Workqueue: events l2cap_chan_timeout<br /> [ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0<br /> [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88<br /> [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246<br /> [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865<br /> [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78<br /> [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f<br /> [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000<br /> [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00<br /> [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000<br /> [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0<br /> [ 472.096136] Call Trace:<br /> [ 472.096136] <br /> [ 472.096136] ? __die_body+0x8d/0xe0<br /> [ 472.096136] ? page_fault_oops+0x6b8/0x9a0<br /> [ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0<br /> [ 472.096136] ? do_user_addr_fault+0x1027/0x1340<br /> [ 472.096136] ? _printk+0x7a/0xa0<br /> [ 472.096136] ? mutex_lock+0x68/0xc0<br /> [ 472.096136] ? add_taint+0x42/0xd0<br /> [ 472.096136] ? exc_page_fault+0x6a/0x1b0<br /> [ 472.096136] ? asm_exc_page_fault+0x26/0x30<br /> [ 472.096136] ? mutex_lock+0x75/0xc0<br /> [ 472.096136] ? mutex_lock+0x88/0xc0<br /> [ 472.096136] ? mutex_lock+0x75/0xc0<br /> [ 472.096136] l2cap_chan_timeo<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: use timestamp to check for set element timeout<br /> <br /> Add a timestamp field at the beginning of the transaction, store it<br /> in the nftables per-netns area.<br /> <br /> Update set backend .insert, .deactivate and sync gc path to use the<br /> timestamp, this avoids that an element expires while control plane<br /> transaction is still unfinished.<br /> <br /> .lookup and .update, which are used from packet path, still use the<br /> current time to check if the element has expired. And .get path and dump<br /> also since this runs lockless under rcu read size lock. Then, there is<br /> async gc which also needs to check the current time since it runs<br /> asynchronously from a workqueue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix Use-After-Free in tcp_ao_connect_init<br /> <br /> Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal<br /> of tcp_ao_connect_init, is not part of the RCU read critical section, it<br /> is possible that the RCU grace period will pass during the traversal and<br /> the key will be free.<br /> <br /> To prevent this, it should be changed to hlist_for_each_entry_safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: Fix Use-After-Free in ovs_ct_exit<br /> <br /> Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal<br /> of ovs_ct_limit_exit, is not part of the RCU read critical section, it<br /> is possible that the RCU grace period will pass during the traversal and<br /> the key will be free.<br /> <br /> To prevent this, it should be changed to hlist_for_each_entry_safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gtp: Fix Use-After-Free in gtp_dellink<br /> <br /> Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal<br /> of gtp_dellink, is not part of the RCU read critical section, it<br /> is possible that the RCU grace period will pass during the traversal and<br /> the key will be free.<br /> <br /> To prevent this, it should be changed to hlist_for_each_entry_safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen-netfront: Add missing skb_mark_for_recycle<br /> <br /> Notice that skb_mark_for_recycle() is introduced later than fixes tag in<br /> commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").<br /> <br /> It is believed that fixes tag were missing a call to page_pool_release_page()<br /> between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().<br /> Since v6.6 the call page_pool_release_page() were removed (in<br /> commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")<br /> and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch<br /> &amp;#39;net-page_pool-remove-page_pool_release_page&amp;#39;")).<br /> <br /> This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch<br /> page_pool memory leaks").

An issue was discovered in RDoc 6.3.3 through 6.6.2, as distributed in Ruby 3.x through 3.3.0. When parsing .rdoc_options (used for configuration in RDoc) as a YAML file, object injection and resultant remote code execution are possible because there are no restrictions on the classes that can be restored. (When loading the documentation cache, object injection and resultant remote code execution are also possible if there were a crafted cache.) The main fixed version is 6.6.3.1. For Ruby 3.0 users, a fixed version is rdoc 6.3.4.1. For Ruby 3.1 users, a fixed version is rdoc 6.4.1.1. For Ruby 3.2 users, a fixed version is rdoc 6.5.1.1.

An issue was discovered in Ruby 3.x through 3.3.0. If attacker-supplied data is provided to the Ruby regex compiler, it is possible to extract arbitrary heap data relative to the start of the text, including pointers and sensitive strings. The fixed versions are 3.0.7, 3.1.5, 3.2.4, and 3.3.1.