Vulnerabilities

An issue was discovered on Thermo Fisher Ion Torrent OneTouch 2 INS1005527 devices. They run an SSH server accessible over the default port 22. The root account has a weak default password of ionadmin, and a password change policy for the root account is not enforced. Thus, an attacker with network connectivity can achieve root code execution. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

The Thermo Fisher Torrent Suite Django application 5.18.1 has weak default credentials, which are stored as fixtures for the Django ORM API. The ionadmin user account can be used to authenticate to default deployments with the password ionadmin. The user guide recommends changing default credentials; however, a password change policy for default administrative accounts is not enforced. Many deployments may retain default credentials, in which case an attacker is likely to be able to successfully authenticate with administrative privileges.

An issue was discovered on Thermo Fisher Ion Torrent OneTouch 2 INS1005527 devices. When they are powered on, an X11 display server is started. The display server listens on all network interfaces and is accessible over port 6000. The X11 access control list, by default, allows connections from 127.0.0.1 and 192.168.2.15. If a device is powered on and later connected to a network with DHCP, the device may not be assigned the 192.168.2.15 IP address, leaving the display server accessible by other devices on the network. The exposed X11 display server can then be used to gain root privileges and the ability to execute code remotely by interacting with matchbox-desktop and spawning a terminal. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

An issue was discovered in the Thermo Fisher Torrent Suite Django application 5.18.1. One of the middlewares included in this application, LocalhostAuthMiddleware, authenticates users as ionadmin if the REMOTE_ADDR property in request.META is set to 127.0.0.1, to 127.0.1.1, or to ::1. Any user with local access to the server may bypass authentication.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix livelock in synchronous file put from fuseblk workers<br /> <br /> I observed a hang when running generic/323 against a fuseblk server.<br /> This test opens a file, initiates a lot of AIO writes to that file<br /> descriptor, and closes the file descriptor before the writes complete.<br /> Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for<br /> responses from the fuseblk server:<br /> <br /> # cat /proc/372265/task/372313/stack<br /> [] request_wait_answer+0x1fe/0x2a0 [fuse]<br /> [] __fuse_simple_request+0xd3/0x2b0 [fuse]<br /> [] fuse_do_getattr+0xfc/0x1f0 [fuse]<br /> [] fuse_file_read_iter+0xbe/0x1c0 [fuse]<br /> [] aio_read+0x130/0x1e0<br /> [] io_submit_one+0x542/0x860<br /> [] __x64_sys_io_submit+0x98/0x1a0<br /> [] do_syscall_64+0x37/0xf0<br /> [] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> But the /weird/ part is that the fuseblk server threads are waiting for<br /> responses from itself:<br /> <br /> # cat /proc/372210/task/372232/stack<br /> [] request_wait_answer+0x1fe/0x2a0 [fuse]<br /> [] __fuse_simple_request+0xd3/0x2b0 [fuse]<br /> [] fuse_file_put+0x9a/0xd0 [fuse]<br /> [] fuse_release+0x36/0x50 [fuse]<br /> [] __fput+0xec/0x2b0<br /> [] task_work_run+0x55/0x90<br /> [] syscall_exit_to_user_mode+0xe9/0x100<br /> [] do_syscall_64+0x43/0xf0<br /> [] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> The fuseblk server is fuse2fs so there&amp;#39;s nothing all that exciting in<br /> the server itself. So why is the fuse server calling fuse_file_put?<br /> The commit message for the fstest sheds some light on that:<br /> <br /> "By closing the file descriptor before calling io_destroy, you pretty<br /> much guarantee that the last put on the ioctx will be done in interrupt<br /> context (during I/O completion).<br /> <br /> Aha. AIO fgets a new struct file from the fd when it queues the ioctx.<br /> The completion of the FUSE_WRITE command from userspace causes the fuse<br /> server to call the AIO completion function. The completion puts the<br /> struct file, queuing a delayed fput to the fuse server task. When the<br /> fuse server task returns to userspace, it has to run the delayed fput,<br /> which in the case of a fuseblk server, it does synchronously.<br /> <br /> Sending the FUSE_RELEASE command sychronously from fuse server threads<br /> is a bad idea because a client program can initiate enough simultaneous<br /> AIOs such that all the fuse server threads end up in delayed_fput, and<br /> now there aren&amp;#39;t any threads left to handle the queued fuse commands.<br /> <br /> Fix this by only using asynchronous fputs when closing files, and leave<br /> a comment explaining why.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pci: mg4b: fix uninitialized iio scan data<br /> <br /> Fix potential leak of uninitialized stack data to userspace by ensuring<br /> that the `scan` structure is zeroed before use.

A vulnerability in Synology Mail Server allows remote authenticated attackers to read and write non-sensitive settings, and disable some non-critical functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: don&amp;#39;t rely on user vaddr alignment<br /> <br /> There is no guaranteed alignment for user pointers, however the<br /> calculation of an offset of the first page into a folio after coalescing<br /> uses some weird bit mask logic, get rid of it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pidfs: validate extensible ioctls<br /> <br /> Validate extensible ioctls stricter than we do now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/vaddr: do not repeat pte_offset_map_lock() until success<br /> <br /> DAMON&amp;#39;s virtual address space operation set implementation (vaddr) calls<br /> pte_offset_map_lock() inside the page table walk callback function. This<br /> is for reading and writing page table accessed bits. If<br /> pte_offset_map_lock() fails, it retries by returning the page table walk<br /> callback function with ACTION_AGAIN.<br /> <br /> pte_offset_map_lock() can continuously fail if the target is a pmd<br /> migration entry, though. Hence it could cause an infinite page table walk<br /> if the migration cannot be done until the page table walk is finished. <br /> This indeed caused a soft lockup when CPU hotplugging and DAMON were<br /> running in parallel.<br /> <br /> Avoid the infinite loop by simply not retrying the page table walk. DAMON<br /> is promising only a best-effort accuracy, so missing access to such pages<br /> is no problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV<br /> <br /> Before disabling SR-IOV via config space accesses to the parent PF,<br /> sriov_disable() first removes the PCI devices representing the VFs.<br /> <br /> Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()")<br /> such removal operations are serialized against concurrent remove and<br /> rescan using the pci_rescan_remove_lock. No such locking was ever added<br /> in sriov_disable() however. In particular when commit 18f9e9d150fc<br /> ("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device<br /> removal into sriov_del_vfs() there was still no locking around the<br /> pci_iov_remove_virtfn() calls.<br /> <br /> On s390 the lack of serialization in sriov_disable() may cause double<br /> remove and list corruption with the below (amended) trace being observed:<br /> <br /> PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56)<br /> GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001<br /> 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480<br /> 0000000000000001 0000000000000000 0000000000000000 0000000180692828<br /> 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8<br /> #0 [3800313fb20] device_del at c9158ad5c<br /> #1 [3800313fb88] pci_remove_bus_device at c915105ba<br /> #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198<br /> #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0<br /> #4 [3800313fc60] zpci_bus_remove_device at c90fb6104<br /> #5 [3800313fca0] __zpci_event_availability at c90fb3dca<br /> #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2<br /> #7 [3800313fd60] crw_collect_info at c91905822<br /> #8 [3800313fe10] kthread at c90feb390<br /> #9 [3800313fe68] __ret_from_fork at c90f6aa64<br /> #10 [3800313fe98] ret_from_fork at c9194f3f2.<br /> <br /> This is because in addition to sriov_disable() removing the VFs, the<br /> platform also generates hot-unplug events for the VFs. This being the<br /> reverse operation to the hotplug events generated by sriov_enable() and<br /> handled via pdev-&gt;no_vf_scan. And while the event processing takes<br /> pci_rescan_remove_lock and checks whether the struct pci_dev still exists,<br /> the lack of synchronization makes this checking racy.<br /> <br /> Other races may also be possible of course though given that this lack of<br /> locking persisted so long observable races seem very rare. Even on s390 the<br /> list corruption was only observed with certain devices since the platform<br /> events are only triggered by config accesses after the removal, so as long<br /> as the removal finished synchronously they would not race. Either way the<br /> locking is missing so fix this by adding it to the sriov_del_vfs() helper.<br /> <br /> Just like PCI rescan-remove, locking is also missing in sriov_add_vfs()<br /> including for the error case where pci_stop_and_remove_bus_device() is<br /> called without the PCI rescan-remove lock being held. Even in the non-error<br /> case, adding new PCI devices and buses should be serialized via the PCI<br /> rescan-remove lock. Add the necessary locking.

A flaw has been found in dayrui XunRuiCMS up to 4.7.1. This vulnerability affects unknown code of the file admin79f2ec220c7e.php?c=api&amp;m=test_site_domain of the component Project Domain Change Test. This manipulation of the argument v causes server-side request forgery. It is possible to initiate the attack remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.