Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix use-after-free in shinker&amp;#39;s callback<br /> <br /> The mmap read lock is used during the shrinker&amp;#39;s callback, which means<br /> that using alloc-&gt;vma pointer isn&amp;#39;t safe as it can race with munmap().<br /> As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in<br /> munmap") the mmap lock is downgraded after the vma has been isolated.<br /> <br /> I was able to reproduce this issue by manually adding some delays and<br /> triggering page reclaiming through the shrinker&amp;#39;s debug sysfs. The<br /> following KASAN report confirms the UAF:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8<br /> Read of size 8 at addr ffff356ed50e50f0 by task bash/478<br /> <br /> CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> zap_page_range_single+0x470/0x4b8<br /> binder_alloc_free_page+0x608/0xadc<br /> __list_lru_walk_one+0x130/0x3b0<br /> list_lru_walk_node+0xc4/0x22c<br /> binder_shrink_scan+0x108/0x1dc<br /> shrinker_debugfs_scan_write+0x2b4/0x500<br /> full_proxy_write+0xd4/0x140<br /> vfs_write+0x1ac/0x758<br /> ksys_write+0xf0/0x1dc<br /> __arm64_sys_write+0x6c/0x9c<br /> <br /> Allocated by task 492:<br /> kmem_cache_alloc+0x130/0x368<br /> vm_area_alloc+0x2c/0x190<br /> mmap_region+0x258/0x18bc<br /> do_mmap+0x694/0xa60<br /> vm_mmap_pgoff+0x170/0x29c<br /> ksys_mmap_pgoff+0x290/0x3a0<br /> __arm64_sys_mmap+0xcc/0x144<br /> <br /> Freed by task 491:<br /> kmem_cache_free+0x17c/0x3c8<br /> vm_area_free_rcu_cb+0x74/0x98<br /> rcu_core+0xa38/0x26d4<br /> rcu_core_si+0x10/0x1c<br /> __do_softirq+0x2fc/0xd24<br /> <br /> Last potentially related work creation:<br /> __call_rcu_common.constprop.0+0x6c/0xba0<br /> call_rcu+0x10/0x1c<br /> vm_area_free+0x18/0x24<br /> remove_vma+0xe4/0x118<br /> do_vmi_align_munmap.isra.0+0x718/0xb5c<br /> do_vmi_munmap+0xdc/0x1fc<br /> __vm_munmap+0x10c/0x278<br /> __arm64_sys_munmap+0x58/0x7c<br /> <br /> Fix this issue by performing instead a vma_lookup() which will fail to<br /> find the vma that was isolated before the mmap lock downgrade. Note that<br /> this option has better performance than upgrading to a mmap write lock<br /> which would increase contention. Plus, mmap_write_trylock() has been<br /> recently removed anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio: Fix use-after-free in uio_open<br /> <br /> core-1 core-2<br /> -------------------------------------------------------<br /> uio_unregister_device uio_open<br /> idev = idr_find()<br /> device_unregister(&amp;idev-&gt;dev)<br /> put_device(&amp;idev-&gt;dev)<br /> uio_device_release<br /> get_device(&amp;idev-&gt;dev)<br /> kfree(idev)<br /> uio_free_minor(minor)<br /> uio_release<br /> put_device(&amp;idev-&gt;dev)<br /> kfree(idev)<br /> -------------------------------------------------------<br /> <br /> In the core-1 uio_unregister_device(), the device_unregister will kfree<br /> idev when the idev-&gt;dev kobject ref is 1. But after core-1<br /> device_unregister, put_device and before doing kfree, the core-2 may<br /> get_device. Then:<br /> 1. After core-1 kfree idev, the core-2 will do use-after-free for idev.<br /> 2. When core-2 do uio_release and put_device, the idev will be double<br /> freed.<br /> <br /> To address this issue, we can get idev atomic &amp; inc idev reference with<br /> minor_lock.

When ssl was enabled for Mongo Hook, default settings included "allow_insecure" which caused that certificates were not validated. This was unexpected and undocumented.<br /> Users are recommended to upgrade to version 4.0.0, which fixes this issue.

Cross Site Scripting vulnerability in the sanitize function in Enhancesoft osTicket 1.18.0 allows a remote attacker to escalate privileges via a crafted support ticket.

Cross Site Scripting (XSS) vulnerability in ProjeQtOr 11.0.2 allows a remote attacker to execute arbitrary code via a crafted script to thecheckvalidHtmlText function in the ack.php and security.php files.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: prevent mss overflow in skb_segment()<br /> <br /> Once again syzbot is able to crash the kernel in skb_segment() [1]<br /> <br /> GSO_BY_FRAGS is a forbidden value, but unfortunately the following<br /> computation in skb_segment() can reach it quite easily :<br /> <br /> mss = mss * partial_segs;<br /> <br /> 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to<br /> a bad final result.<br /> <br /> Make sure to limit segmentation so that the new mss value is smaller<br /> than GSO_BY_FRAGS.<br /> <br /> [1]<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]<br /> CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023<br /> RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551<br /> Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00<br /> RSP: 0018:ffffc900043473d0 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597<br /> RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070<br /> RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff<br /> R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0<br /> R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046<br /> FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109<br /> ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120<br /> skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53<br /> __skb_gso_segment+0x339/0x710 net/core/gso.c:124<br /> skb_gso_segment include/net/gso.h:83 [inline]<br /> validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626<br /> __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338<br /> dev_queue_xmit include/linux/netdevice.h:3134 [inline]<br /> packet_xmit+0x257/0x380 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3087 [inline]<br /> packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0xd5/0x180 net/socket.c:745<br /> __sys_sendto+0x255/0x340 net/socket.c:2190<br /> __do_sys_sendto net/socket.c:2202 [inline]<br /> __se_sys_sendto net/socket.c:2198 [inline]<br /> __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> RIP: 0033:0x7f8692032aa9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9<br /> RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003<br /> RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480<br /> R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551<br /> Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00<br /> RSP: 0018:ffffc900043473d0 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597<br /> RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070<br /> RBP: ffffc90004347578 R0<br /> ---truncated---

MeshCentral is a full computer management web site. Versions prior to 1.1.21 a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. The vulnerability is exploitable when an attacker is able to convince a victim end-user to click on a malicious link to a page hosting an attacker-controlled site. The attacker can then originate a cross-site websocket connection using client-side JavaScript code to connect to `control.ashx` as the victim user within MeshCentral. Version 1.1.21 contains a patch for this issue.

Cilium is a networking, observability, and security solution with an eBPF-based dataplane. For Cilium users who have enabled an external kvstore and Wireguard transparent encryption, traffic between pods in the affected cluster is not encrypted. This issue affects Cilium v1.14 before v1.14.7 and has been patched in Cilium v1.14.7. There is no workaround to this issue.

QEMU before 8.2.0 has an integer underflow, and resultant buffer overflow, via a TI command when an expected non-DMA transfer length is less than the length of the available FIFO data. This occurs in esp_do_nodma in hw/scsi/esp.c because of an underflow of async_len.

JumpServer is an open source bastion host and an operation and maintenance security audit system. Prior to version 3.10.0, attackers can exploit this vulnerability to construct malicious links, leading users to click on them, thereby facilitating phishing attacks or cross-site scripting attacks. Version 3.10.0 contains a patch for this issue. No known workarounds are available.

elfutils v0.189 was discovered to contain a NULL pointer dereference via the handle_verdef() function at readelf.c.

Cilium is a networking, observability, and security solution with an eBPF-based dataplane. For Cilium users who are using CRDs to store Cilium state (the default configuration) and Wireguard transparent encryption, traffic to/from the Ingress and health endpoints is not encrypted. This issue affects Cilium v1.14 before v1.14.7 and has been patched in Cilium v1.14.7. There is no workaround to this issue.