Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcachefs: grab s_umount only if snapshotting<br /> <br /> When I was testing mongodb over bcachefs with compression,<br /> there is a lockdep warning when snapshotting mongodb data volume.<br /> <br /> $ cat test.sh<br /> prog=bcachefs<br /> <br /> $prog subvolume create /mnt/data<br /> $prog subvolume create /mnt/data/snapshots<br /> <br /> while true;do<br /> $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s)<br /> sleep 1s<br /> done<br /> <br /> $ cat /etc/mongodb.conf<br /> systemLog:<br /> destination: file<br /> logAppend: true<br /> path: /mnt/data/mongod.log<br /> <br /> storage:<br /> dbPath: /mnt/data/<br /> <br /> lockdep reports:<br /> [ 3437.452330] ======================================================<br /> [ 3437.452750] WARNING: possible circular locking dependency detected<br /> [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E<br /> [ 3437.453562] ------------------------------------------------------<br /> [ 3437.453981] bcachefs/35533 is trying to acquire lock:<br /> [ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190<br /> [ 3437.454875]<br /> but task is already holding lock:<br /> [ 3437.455268] ffffa0a02b2b10e0 (&amp;type-&gt;s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]<br /> [ 3437.456009]<br /> which lock already depends on the new lock.<br /> <br /> [ 3437.456553]<br /> the existing dependency chain (in reverse order) is:<br /> [ 3437.457054]<br /> -&gt; #3 (&amp;type-&gt;s_umount_key#48){.+.+}-{3:3}:<br /> [ 3437.457507] down_read+0x3e/0x170<br /> [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]<br /> [ 3437.458206] __x64_sys_ioctl+0x93/0xd0<br /> [ 3437.458498] do_syscall_64+0x42/0xf0<br /> [ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 3437.459155]<br /> -&gt; #2 (&amp;c-&gt;snapshot_create_lock){++++}-{3:3}:<br /> [ 3437.459615] down_read+0x3e/0x170<br /> [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs]<br /> [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs]<br /> [ 3437.460686] notify_change+0x1f1/0x4a0<br /> [ 3437.461283] do_truncate+0x7f/0xd0<br /> [ 3437.461555] path_openat+0xa57/0xce0<br /> [ 3437.461836] do_filp_open+0xb4/0x160<br /> [ 3437.462116] do_sys_openat2+0x91/0xc0<br /> [ 3437.462402] __x64_sys_openat+0x53/0xa0<br /> [ 3437.462701] do_syscall_64+0x42/0xf0<br /> [ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 3437.463359]<br /> -&gt; #1 (&amp;sb-&gt;s_type-&gt;i_mutex_key#15){+.+.}-{3:3}:<br /> [ 3437.463843] down_write+0x3b/0xc0<br /> [ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs]<br /> [ 3437.464493] vfs_write+0x21b/0x4c0<br /> [ 3437.464653] ksys_write+0x69/0xf0<br /> [ 3437.464839] do_syscall_64+0x42/0xf0<br /> [ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 3437.465231]<br /> -&gt; #0 (sb_writers#10){.+.+}-{0:0}:<br /> [ 3437.465471] __lock_acquire+0x1455/0x21b0<br /> [ 3437.465656] lock_acquire+0xc6/0x2b0<br /> [ 3437.465822] mnt_want_write+0x46/0x1a0<br /> [ 3437.465996] filename_create+0x62/0x190<br /> [ 3437.466175] user_path_create+0x2d/0x50<br /> [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs]<br /> [ 3437.466617] __x64_sys_ioctl+0x93/0xd0<br /> [ 3437.466791] do_syscall_64+0x42/0xf0<br /> [ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 3437.467180]<br /> other info that might help us debug this:<br /> <br /> [ 3437.469670] 2 locks held by bcachefs/35533:<br /> other info that might help us debug this:<br /> <br /> [ 3437.467507] Chain exists of:<br /> sb_writers#10 --&gt; &amp;c-&gt;snapshot_create_lock --&gt; &amp;type-&gt;s_umount_key#48<br /> <br /> [ 3437.467979] Possible unsafe locking scenario:<br /> <br /> [ 3437.468223] CPU0 CPU1<br /> [ 3437.468405] ---- ----<br /> [ 3437.468585] rlock(&amp;type-&gt;s_umount_key#48);<br /> [ 3437.468758] lock(&amp;c-&gt;snapshot_create_lock);<br /> [ 3437.469030] lock(&amp;type-&gt;s_umount_key#48);<br /> [ 3437.469291] rlock(sb_writers#10);<br /> [ 3437.469434]<br /> *** DEADLOCK ***<br /> <br /> [ 3437.469<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: handle isoc Babble and Buffer Overrun events properly<br /> <br /> xHCI 4.9 explicitly forbids assuming that the xHC has released its<br /> ownership of a multi-TRB TD when it reports an error on one of the<br /> early TRBs. Yet the driver makes such assumption and releases the TD,<br /> allowing the remaining TRBs to be freed or overwritten by new TDs.<br /> <br /> The xHC should also report completion of the final TRB due to its IOC<br /> flag being set by us, regardless of prior errors. This event cannot<br /> be recognized if the TD has already been freed earlier, resulting in<br /> "Transfer event TRB DMA ptr not part of current TD" error message.<br /> <br /> Fix this by reusing the logic for processing isoc Transaction Errors.<br /> This also handles hosts which fail to report the final completion.<br /> <br /> Fix transfer length reporting on Babble errors. They may be caused by<br /> device malfunction, no guarantee that the buffer has been filled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix use-after-free bug<br /> <br /> The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl<br /> to the AMDGPU DRM driver on any ASICs with an invalid address and size.<br /> The bug was reported by Joonkyo Jung .<br /> For example the following code:<br /> <br /> static void Syzkaller1(int fd)<br /> {<br /> struct drm_amdgpu_gem_userptr arg;<br /> int ret;<br /> <br /> arg.addr = 0xffffffffffff0000;<br /> arg.size = 0x80000000; /*2 Gb*/<br /> arg.flags = 0x7;<br /> ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &amp;arg);<br /> }<br /> <br /> Due to the address and size are not valid there is a failure in<br /> amdgpu_hmm_register-&gt;mmu_interval_notifier_insert-&gt;__mmu_interval_notifier_insert-&gt;<br /> check_shl_overflow, but we even the amdgpu_hmm_register failure we still call<br /> amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address.<br /> The following stack is below when the issue is reproduced when Kazan is enabled:<br /> <br /> [ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020<br /> [ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340<br /> [ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80<br /> [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246<br /> [ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b<br /> [ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260<br /> [ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25<br /> [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00<br /> [ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260<br /> [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000<br /> [ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0<br /> [ +0.000010] Call Trace:<br /> [ +0.000006] <br /> [ +0.000007] ? show_regs+0x6a/0x80<br /> [ +0.000018] ? __warn+0xa5/0x1b0<br /> [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340<br /> [ +0.000018] ? report_bug+0x24a/0x290<br /> [ +0.000022] ? handle_bug+0x46/0x90<br /> [ +0.000015] ? exc_invalid_op+0x19/0x50<br /> [ +0.000016] ? asm_exc_invalid_op+0x1b/0x20<br /> [ +0.000017] ? kasan_save_stack+0x26/0x50<br /> [ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340<br /> [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340<br /> [ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340<br /> [ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10<br /> [ +0.000017] ? kasan_save_alloc_info+0x1e/0x30<br /> [ +0.000018] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? __kasan_kmalloc+0xb1/0xc0<br /> [ +0.000018] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? __kasan_check_read+0x11/0x20<br /> [ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu]<br /> [ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu]<br /> [ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]<br /> [ +0.004291] ? do_syscall_64+0x5f/0xe0<br /> [ +0.000023] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000017] drm_gem_object_free+0x3b/0x50 [drm]<br /> [ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]<br /> [ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]<br /> [ +0.004270] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? __this_cpu_preempt_check+0x13/0x20<br /> [ +0.000015] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0<br /> [ +0.000020] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20<br /> [ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm]<br /> [ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]<br /> [ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm]<br /> [ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm]<br /> [ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]<br /> [ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix lock dependency warning with srcu<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.5.0-kfd-yangp #2289 Not tainted<br /> ------------------------------------------------------<br /> kworker/0:2/996 is trying to acquire lock:<br /> (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0<br /> <br /> but task is already holding lock:<br /> ((work_completion)(&amp;svms-&gt;deferred_list_work)){+.+.}-{0:0}, at:<br /> process_one_work+0x211/0x560<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #3 ((work_completion)(&amp;svms-&gt;deferred_list_work)){+.+.}-{0:0}:<br /> __flush_work+0x88/0x4f0<br /> svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu]<br /> svm_range_set_attr+0xd6/0x14c0 [amdgpu]<br /> kfd_ioctl+0x1d1/0x630 [amdgpu]<br /> __x64_sys_ioctl+0x88/0xc0<br /> <br /> -&gt; #2 (&amp;info-&gt;lock#2){+.+.}-{3:3}:<br /> __mutex_lock+0x99/0xc70<br /> amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu]<br /> restore_process_helper+0x22/0x80 [amdgpu]<br /> restore_process_worker+0x2d/0xa0 [amdgpu]<br /> process_one_work+0x29b/0x560<br /> worker_thread+0x3d/0x3d0<br /> <br /> -&gt; #1 ((work_completion)(&amp;(&amp;process-&gt;restore_work)-&gt;work)){+.+.}-{0:0}:<br /> __flush_work+0x88/0x4f0<br /> __cancel_work_timer+0x12c/0x1c0<br /> kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]<br /> __mmu_notifier_release+0xad/0x240<br /> exit_mmap+0x6a/0x3a0<br /> mmput+0x6a/0x120<br /> do_exit+0x322/0xb90<br /> do_group_exit+0x37/0xa0<br /> __x64_sys_exit_group+0x18/0x20<br /> do_syscall_64+0x38/0x80<br /> <br /> -&gt; #0 (srcu){.+.+}-{0:0}:<br /> __lock_acquire+0x1521/0x2510<br /> lock_sync+0x5f/0x90<br /> __synchronize_srcu+0x4f/0x1a0<br /> __mmu_notifier_release+0x128/0x240<br /> exit_mmap+0x6a/0x3a0<br /> mmput+0x6a/0x120<br /> svm_range_deferred_list_work+0x19f/0x350 [amdgpu]<br /> process_one_work+0x29b/0x560<br /> worker_thread+0x3d/0x3d0<br /> <br /> other info that might help us debug this:<br /> Chain exists of:<br /> srcu --&gt; &amp;info-&gt;lock#2 --&gt; (work_completion)(&amp;svms-&gt;deferred_list_work)<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock((work_completion)(&amp;svms-&gt;deferred_list_work));<br /> lock(&amp;info-&gt;lock#2);<br /> lock((work_completion)(&amp;svms-&gt;deferred_list_work));<br /> sync(srcu);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: time-travel: fix time corruption<br /> <br /> In &amp;#39;basic&amp;#39; time-travel mode (without =inf-cpu or =ext), we<br /> still get timer interrupts. These can happen at arbitrary<br /> points in time, i.e. while in timer_read(), which pushes<br /> time forward just a little bit. Then, if we happen to get<br /> the interrupt after calculating the new time to push to,<br /> but before actually finishing that, the interrupt will set<br /> the time to a value that&amp;#39;s incompatible with the forward,<br /> and we&amp;#39;ll crash because time goes backwards when we do the<br /> forwarding.<br /> <br /> Fix this by reading the time_travel_time, calculating the<br /> adjustment, and doing the adjustment all with interrupts<br /> disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix disable_otg_wa logic<br /> <br /> [Why]<br /> When switching to another HDMI mode, we are unnecesarilly<br /> disabling/enabling FIFO causing both HPO and DIG registers to be set at<br /> the same time when only HPO is supposed to be set.<br /> <br /> This can lead to a system hang the next time we change refresh rates as<br /> there are cases when we don&amp;#39;t disable OTG/FIFO but FIFO is enabled when<br /> it isn&amp;#39;t supposed to be.<br /> <br /> [How]<br /> Removing the enable/disable FIFO entirely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: Synchronize devfreq_monitor_[start/stop]<br /> <br /> There is a chance if a frequent switch of the governor<br /> done in a loop result in timer list corruption where<br /> timer cancel being done from two place one from<br /> cancel_delayed_work_sync() and followed by expire_timers()<br /> can be seen from the traces[1].<br /> <br /> while true<br /> do<br /> echo "simple_ondemand" &gt; /sys/class/devfreq/1d84000.ufshc/governor<br /> echo "performance" &gt; /sys/class/devfreq/1d84000.ufshc/governor<br /> done<br /> <br /> It looks to be issue with devfreq driver where<br /> device_monitor_[start/stop] need to synchronized so that<br /> delayed work should get corrupted while it is either<br /> being queued or running or being cancelled.<br /> <br /> Let&amp;#39;s use polling flag and devfreq lock to synchronize the<br /> queueing the timer instance twice and work data being<br /> corrupted.<br /> <br /> [1]<br /> ...<br /> ..<br /> -0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428<br /> -0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c<br /> -0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428<br /> kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227<br /> vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428<br /> vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428<br /> vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532<br /> vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428<br /> xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428<br /> <br /> [2]<br /> <br /> 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a<br /> [ 9436.261664][ C4] Mem abort info:<br /> [ 9436.261666][ C4] ESR = 0x96000044<br /> [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 9436.261671][ C4] SET = 0, FnV = 0<br /> [ 9436.261673][ C4] EA = 0, S1PTW = 0<br /> [ 9436.261675][ C4] Data abort info:<br /> [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044<br /> [ 9436.261680][ C4] CM = 0, WnR = 1<br /> [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges<br /> [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP<br /> [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0<br /> ...<br /> <br /> [ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1<br /> [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT)<br /> [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)<br /> [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438<br /> [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438<br /> [ 9436.262168][ C4] sp : ffffffc010023dd0<br /> [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18<br /> [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008<br /> [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280<br /> [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122<br /> [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80<br /> [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038<br /> [ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201<br /> [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100<br /> [ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8<br /> [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff<br /> [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122<br /> [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8<br /> [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101<br /> [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: just wait for more data to be available on the socket<br /> <br /> A short read may occur while reading the message footer from the<br /> socket. Later, when the socket is ready for another read, the<br /> messenger invokes all read_partial_*() handlers, including<br /> read_partial_sparse_msg_data(). The expectation is that<br /> read_partial_sparse_msg_data() would bail, allowing the messenger to<br /> invoke read_partial() for the footer and pick up where it left off.<br /> <br /> However read_partial_sparse_msg_data() violates that and ends up<br /> calling into the state machine in the OSD client. The sparse-read<br /> state machine assumes that it&amp;#39;s a new op and interprets some piece of<br /> the footer as the sparse-read header and returns bogus extents/data<br /> length, etc.<br /> <br /> To determine whether read_partial_sparse_msg_data() should bail, let&amp;#39;s<br /> reuse cursor-&gt;total_resid. Because once it reaches to zero that means<br /> all the extents and data have been successfully received in last read,<br /> else it could break out when partially reading any of the extents and<br /> data. And then osd_sparse_read() could continue where it left off.<br /> <br /> [ idryomov: changelog ]

in OpenHarmony v3.2.4 and prior versions allow a local attacker cause apps crash through type confusion.

in OpenHarmony v3.2.4 and prior versions allow a remote attacker bypass permission verification to install apps, although these require user action.

in OpenHarmony v3.2.4 and prior versions allow a local attacker arbitrary code execution in any apps through use after free.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.