Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net-sysfs: add check for netdevice being present to speed_show<br /> <br /> When bringing down the netdevice or system shutdown, a panic can be<br /> triggered while accessing the sysfs path because the device is already<br /> removed.<br /> <br /> [ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called<br /> [ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called<br /> ...<br /> [ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)<br /> [ 758.031397] IP: [] dma_pool_alloc+0x1ab/0x280<br /> <br /> crash&gt; bt<br /> ...<br /> PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"<br /> ...<br /> #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778<br /> [exception RIP: dma_pool_alloc+0x1ab]<br /> RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046<br /> RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000<br /> RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090<br /> RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00<br /> R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0<br /> R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]<br /> #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]<br /> #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]<br /> #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]<br /> #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]<br /> #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]<br /> #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]<br /> #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46<br /> #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208<br /> #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3<br /> #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf<br /> #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596<br /> #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10<br /> #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5<br /> #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff<br /> #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f<br /> #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92<br /> <br /> crash&gt; net_device.state ffff89443b0c0000<br /> state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)<br /> <br /> To prevent this scenario, we also make sure that the netdevice is present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: gdm724x: fix use after free in gdm_lte_rx()<br /> <br /> The netif_rx_ni() function frees the skb so we can&amp;#39;t dereference it to<br /> save the skb-&gt;len.