Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: prevent poison consumption when splitting THP<br /> <br /> When performing memory error injection on a THP (Transparent Huge Page)<br /> mapped to userspace on an x86 server, the kernel panics with the following<br /> trace. The expected behavior is to terminate the affected process instead<br /> of panicking the kernel, as the x86 Machine Check code can recover from an<br /> in-userspace #MC.<br /> <br /> mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134<br /> mce: [Hardware Error]: RIP 10: {memchr_inv+0x4c/0xf0}<br /> mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db<br /> mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320<br /> mce: [Hardware Error]: Run the above through &amp;#39;mcelog --ascii&amp;#39;<br /> mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel<br /> Kernel panic - not syncing: Fatal local machine check<br /> <br /> The root cause of this panic is that handling a memory failure triggered<br /> by an in-userspace #MC necessitates splitting the THP. The splitting<br /> process employs a mechanism, implemented in<br /> try_to_map_unused_to_zeropage(), which reads the pages in the THP to<br /> identify zero-filled pages. However, reading the pages in the THP results<br /> in a second in-kernel #MC, occurring before the initial memory_failure()<br /> completes, ultimately leading to a kernel panic. See the kernel panic<br /> call trace on the two #MCs.<br /> <br /> First Machine Check occurs // [1]<br /> memory_failure() // [2]<br /> try_to_split_thp_page()<br /> split_huge_page()<br /> split_huge_page_to_list_to_order()<br /> __folio_split() // [3]<br /> remap_page()<br /> remove_migration_ptes()<br /> remove_migration_pte()<br /> try_to_map_unused_to_zeropage() // [4]<br /> memchr_inv() // [5]<br /> Second Machine Check occurs // [6]<br /> Kernel panic<br /> <br /> [1] Triggered by accessing a hardware-poisoned THP in userspace, which is<br /> typically recoverable by terminating the affected process.<br /> <br /> [2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page().<br /> <br /> [3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page().<br /> <br /> [4] Try to map the unused THP to zeropage.<br /> <br /> [5] Re-access pages in the hw-poisoned THP in the kernel.<br /> <br /> [6] Triggered in-kernel, leading to a panic kernel.<br /> <br /> In Step[2], memory_failure() sets the poisoned flag on the page in the THP<br /> by TestSetPageHWPoison() before calling try_to_split_thp_page().<br /> <br /> As suggested by David Hildenbrand, fix this panic by not accessing to the<br /> poisoned page in the THP during zeropage identification, while continuing<br /> to scan unaffected pages in the THP for possible zeropage mapping. This<br /> prevents a second in-kernel #MC that would cause kernel panic in Step[4].<br /> <br /> Thanks to Andrew Zaborowski for his initial work on fixing this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: fix lock inversion in vsock_assign_transport()<br /> <br /> Syzbot reported a potential lock inversion deadlock between<br /> vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.<br /> <br /> The issue was introduced by commit 687aa0c5581b ("vsock: Fix<br /> transport_* TOCTOU") which added vsock_register_mutex locking in<br /> vsock_assign_transport() around the transport-&gt;release() call, that can<br /> call vsock_linger(). vsock_assign_transport() can be called with sk_lock<br /> held. vsock_linger() calls sk_wait_event() that temporarily releases and<br /> re-acquires sk_lock. During this window, if another thread hold<br /> vsock_register_mutex while trying to acquire sk_lock, a circular<br /> dependency is created.<br /> <br /> Fix this by releasing vsock_register_mutex before calling<br /> transport-&gt;release() and vsock_deassign_transport(). This is safe<br /> because we don&amp;#39;t need to hold vsock_register_mutex while releasing the<br /> old transport, and we ensure the new transport won&amp;#39;t disappear by<br /> obtaining a module reference first via try_module_get().

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.

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.

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.