Vulnerabilities

Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. Reason: This candidate was issued in error. Notes: All references and descriptions in this candidate have been removed to prevent accidental usage.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: sh-sci: fix RSCI FIFO overrun handling<br /> <br /> The receive error handling code is shared between RSCI and all other<br /> SCIF port types, but the RSCI overrun_reg is specified as a memory<br /> offset, while for other SCIF types it is an enum value used to index<br /> into the sci_port_params-&gt;regs array, as mentioned above the<br /> sci_serial_in() function.<br /> <br /> For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call<br /> inside the sci_handle_fifo_overrun() function to index outside the<br /> bounds of the regs array, which currently has a size of 20, as specified<br /> by SCI_NR_REGS.<br /> <br /> Because of this, we end up accessing memory outside of RSCI&amp;#39;s<br /> rsci_port_params structure, which, when interpreted as a plat_sci_reg,<br /> happens to have a non-zero size, causing the following WARN when<br /> sci_serial_in() is called, as the accidental size does not match the<br /> supported register sizes.<br /> <br /> The existence of the overrun_reg needs to be checked because<br /> SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not<br /> present in the regs array.<br /> <br /> Avoid calling sci_getreg() for port types which don&amp;#39;t use standard<br /> register handling.<br /> <br /> Use the ops-&gt;read_reg() and ops-&gt;write_reg() functions to properly read<br /> and write registers for RSCI, and change the type of the status variable<br /> to accommodate the 32-bit CSR register.<br /> <br /> sci_getreg() and sci_serial_in() are also called with overrun_reg in the<br /> sci_mpxed_interrupt() interrupt handler, but that code path is not used<br /> for RSCI, as it does not have a muxed interrupt.<br /> <br /> ------------[ cut here ]------------<br /> Invalid register access<br /> WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac<br /> Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT<br /> Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT)<br /> pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : sci_serial_in+0x38/0xac<br /> lr : sci_serial_in+0x38/0xac<br /> sp : ffff800080003e80<br /> x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d<br /> x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80<br /> x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000<br /> x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a<br /> x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720<br /> x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720<br /> x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48<br /> x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48<br /> x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80<br /> Call trace:<br /> sci_serial_in+0x38/0xac (P)<br /> sci_handle_fifo_overrun.isra.0+0x70/0x134<br /> sci_er_interrupt+0x50/0x39c<br /> __handle_irq_event_percpu+0x48/0x140<br /> handle_irq_event+0x44/0xb0<br /> handle_fasteoi_irq+0xf4/0x1a0<br /> handle_irq_desc+0x34/0x58<br /> generic_handle_domain_irq+0x1c/0x28<br /> gic_handle_irq+0x4c/0x140<br /> call_on_irq_stack+0x30/0x48<br /> do_interrupt_handler+0x80/0x84<br /> el1_interrupt+0x34/0x68<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x6c/0x70<br /> default_idle_call+0x28/0x58 (P)<br /> do_idle+0x1f8/0x250<br /> cpu_startup_entry+0x34/0x3c<br /> rest_init+0xd8/0xe0<br /> console_on_rootfs+0x0/0x6c<br /> __primary_switched+0x88/0x90<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: usb: Fix use-after-free in hdm_disconnect<br /> <br /> hdm_disconnect() calls most_deregister_interface(), which eventually<br /> unregisters the MOST interface device with device_unregister(iface-&gt;dev).<br /> If that drops the last reference, the device core may call release_mdev()<br /> immediately while hdm_disconnect() is still executing.<br /> <br /> The old code also freed several mdev-owned allocations in<br /> hdm_disconnect() and then performed additional put_device() calls.<br /> Depending on refcount order, this could lead to use-after-free or<br /> double-free when release_mdev() ran (or when unregister paths also<br /> performed puts).<br /> <br /> Fix by moving the frees of mdev-owned allocations into release_mdev(),<br /> so they happen exactly once when the device is truly released, and by<br /> dropping the extra put_device() calls in hdm_disconnect() that are<br /> redundant after device_unregister() and most_deregister_interface().<br /> <br /> This addresses the KASAN slab-use-after-free reported by syzbot in<br /> hdm_disconnect(). See report and stack traces in the bug link below.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (cgbc-hwmon) Add missing NULL check after devm_kzalloc()<br /> <br /> The driver allocates memory for sensor data using devm_kzalloc(), but<br /> did not check if the allocation succeeded. In case of memory allocation<br /> failure, dereferencing the NULL pointer would lead to a kernel crash.<br /> <br /> Add a NULL pointer check and return -ENOMEM to handle allocation failure<br /> properly.

alexusmai laravel-file-manager 3.3.1 and below is vulnerable to Directory Traversal. The unzip/extraction functionality improperly allows archive contents to be written to arbitrary locations on the filesystem due to insufficient validation of extraction paths.

An issue was discovered in the Thermo Fisher Torrent Suite Django application 5.18.1. The /configure/plugins/plugin/upload/zip/ and /configure/newupdates/offline/bundle/upload/ endpoints allow low-privilege users to upload ZIP files to the server. The plupload_file_upload function handles these file uploads and constructs the destination file path by using either the name parameter or the uploaded filename, neither of which is properly sanitized. The file extension is extracted by splitting the filename, and a format string is used to construct the final file path, leaving the destination path vulnerable to path traversal. An authenticated attacker with network connectivity can write arbitrary files to the server, enabling remote code execution after overwriting an executable file. An example is the pdflatex executable, which is executed through subprocess.Popen in the write_report_pdf function after requests to a /report/latex/(\d+).pdf endpoint.

An issue was discovered in the Thermo Fisher Torrent Suite Django application 5.18.1. A remote code execution vulnerability exists in the network configuration functionality, stemming from insufficient input validation when processing network configuration parameters through administrative endpoints. The application allows administrators to modify the server&amp;#39;s network configuration through the Django application. This configuration is processed by Bash scripts (TSsetnoproxy and TSsetproxy) that write user-controlled data directly to environment variables without proper sanitization. After updating environment variables, the scripts execute a source command on /etc/environment; if an attacker injects malicious data into environment variables, this command can enable arbitrary command execution. The vulnerability begins with the /admin/network endpoint, which passes user-supplied form data as arguments to subprocess.Popen calls. The user-supplied input is then used to update environment variables in TSsetnoproxy and TSsetproxy, and finally source $environment is executed.

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.

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.

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. 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.

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.