Vulnerabilities

Under certain circumstances the impacted Software House C•CURE 9000 installer will utilize unnecessarily wide permissions.

A flaw was found in the GTK library. Under certain conditions, it is possible for a library to be injected into a GTK application from the current working directory.

Sensitive information disclosure due to excessive privileges assigned to Acronis Agent. The following products are affected: Acronis Cyber Protect 15 (Windows, Linux) before build 30984.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa: fix use-after-free on vp_vdpa_remove<br /> <br /> When vp_vdpa driver is unbind, vp_vdpa is freed in vdpa_unregister_device<br /> and then vp_vdpa-&gt;mdev.pci_dev is dereferenced in vp_modern_remove,<br /> triggering use-after-free.<br /> <br /> Call Trace of unbinding driver free vp_vdpa :<br /> do_syscall_64<br /> vfs_write<br /> kernfs_fop_write_iter<br /> device_release_driver_internal<br /> pci_device_remove<br /> vp_vdpa_remove<br /> vdpa_unregister_device<br /> kobject_release<br /> device_release<br /> kfree<br /> <br /> Call Trace of dereference vp_vdpa-&gt;mdev.pci_dev:<br /> vp_modern_remove<br /> pci_release_selected_regions<br /> pci_release_region<br /> pci_resource_len<br /> pci_resource_end<br /> (dev)-&gt;resource[(bar)].end

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost: fix hung thread due to erroneous iotlb entries<br /> <br /> In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when<br /> start is 0 and last is ULONG_MAX. One instance where it can happen<br /> is when userspace sends an IOTLB message with iova=size=uaddr=0<br /> (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0,<br /> last = ULONG_MAX ends up in the iotlb. Next time a packet is sent,<br /> iotlb_access_ok() loops indefinitely due to that erroneous entry.<br /> <br /> Call Trace:<br /> <br /> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340<br /> vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366<br /> vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104<br /> vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:377<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295<br /> <br /> <br /> Reported by syzbot at:<br /> https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87<br /> <br /> To fix this, do two things:<br /> <br /> 1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map<br /> a range with size 0.<br /> 2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]<br /> by splitting it into two entries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: Fix memory leak in dsp_pipeline_build()<br /> <br /> dsp_pipeline_build() allocates dup pointer by kstrdup(cfg),<br /> but then it updates dup variable by strsep(&amp;dup, "|").<br /> As a result when it calls kfree(dup), the dup variable contains NULL.<br /> <br /> Found by Linux Driver Verification project (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command<br /> <br /> When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command<br /> request from the driver, presently there is no validation against the<br /> number of queue pairs to configure, or even if multiqueue had been<br /> negotiated or not is unverified. This may lead to kernel panic due to<br /> uninitialized resource for the queues were there any bogus request<br /> sent down by untrusted driver. Tie up the loose ends there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix kernel panic when enabling bearer<br /> <br /> When enabling a bearer on a node, a kernel panic is observed:<br /> <br /> [ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]<br /> ...<br /> [ 4.520030] Call Trace:<br /> [ 4.520689] <br /> [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc]<br /> [ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc]<br /> [ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc]<br /> [ 4.525292] tipc_rcv+0x5da/0x730 [tipc]<br /> [ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0<br /> [ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc]<br /> [ 4.528737] __netif_receive_skb_list_core+0x20b/0x260<br /> [ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0<br /> [ 4.531450] ? dev_gro_receive+0x4c2/0x680<br /> [ 4.532512] napi_complete_done+0x6f/0x180<br /> [ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]<br /> ...<br /> <br /> The node in question is receiving activate messages in another<br /> thread after changing bearer status to allow message sending/<br /> receiving in current thread:<br /> <br /> thread 1 | thread 2<br /> -------- | --------<br /> |<br /> tipc_enable_bearer() |<br /> test_and_set_bit_lock() |<br /> tipc_bearer_xmit_skb() |<br /> | tipc_l2_rcv_msg()<br /> | tipc_rcv()<br /> | __tipc_node_link_up()<br /> | tipc_link_build_state_msg()<br /> | tipc_link_build_proto_msg()<br /> | tipc_mon_prep()<br /> | {<br /> | ...<br /> | // null-pointer dereference<br /> | u16 gen = mon-&gt;dom_gen;<br /> | ...<br /> | }<br /> // Not being executed yet |<br /> tipc_mon_create() |<br /> { |<br /> ... |<br /> // allocate |<br /> mon = kzalloc(); |<br /> ... |<br /> } |<br /> <br /> Monitoring pointer in thread 2 is dereferenced before monitoring data<br /> is allocated in thread 1. This causes kernel panic.<br /> <br /> This commit fixes it by allocating the monitoring data before enabling<br /> the bearer to receive messages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts<br /> <br /> Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug.<br /> The root case is in missing validation check of actual number of endpoints.<br /> <br /> Code should not blindly access usb_host_interface::endpoint array, since<br /> it may contain less endpoints than code expects.<br /> <br /> Fix it by adding missing validaion check and print an error if<br /> number of endpoints do not match expected number

A privilege escalation vulnerability exists in the affected products which could allow a malicious user with basic privileges to access functions which should only be available to users with administrative level privileges. If exploited, an attacker could read sensitive data, and create users. For example, a malicious user with basic privileges could perform critical functions such as creating a user with elevated privileges and reading sensitive information in the “views” section.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/osnoise: Do not unregister events twice<br /> <br /> Nicolas reported that using:<br /> <br /> # trace-cmd record -e all -M 10 -p osnoise --poll<br /> <br /> Resulted in the following kernel warning:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370<br /> [...]<br /> CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19<br /> RIP: 0010:tracepoint_probe_unregister+0x280/0x370<br /> [...]<br /> CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0<br /> Call Trace:<br /> <br /> osnoise_workload_stop+0x36/0x90<br /> tracing_set_tracer+0x108/0x260<br /> tracing_set_trace_write+0x94/0xd0<br /> ? __check_object_size.part.0+0x10a/0x150<br /> ? selinux_file_permission+0x104/0x150<br /> vfs_write+0xb5/0x290<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7ff919a18127<br /> [...]<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The warning complains about an attempt to unregister an<br /> unregistered tracepoint.<br /> <br /> This happens on trace-cmd because it first stops tracing, and<br /> then switches the tracer to nop. Which is equivalent to:<br /> <br /> # cd /sys/kernel/tracing/<br /> # echo osnoise &gt; current_tracer<br /> # echo 0 &gt; tracing_on<br /> # echo nop &gt; current_tracer<br /> <br /> The osnoise tracer stops the workload when no trace instance<br /> is actually collecting data. This can be caused both by<br /> disabling tracing or disabling the tracer itself.<br /> <br /> To avoid unregistering events twice, use the existing<br /> trace_osnoise_callback_enabled variable to check if the events<br /> (and the workload) are actually active before trying to<br /> deactivate them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: bypass tiling flag check in virtual display case (v2)<br /> <br /> vkms leverages common amdgpu framebuffer creation, and<br /> also as it does not support FB modifier, there is no need<br /> to check tiling flags when initing framebuffer when virtual<br /> display is enabled.<br /> <br /> This can fix below calltrace:<br /> <br /> amdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier<br /> WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu]<br /> <br /> v2: check adev-&gt;enable_virtual_display instead as vkms can be<br /> enabled in bare metal as well.