Vulnerabilities

In Zephyr&amp;#39;s userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock.<br /> <br /> On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx.<br /> <br /> The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object&amp;#39;s perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &amp;=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool.<br /> <br /> The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and including v4.4.0. Fixed by holding lists_lock across the bitmap RMW and the permissions clear (and inlining the obj_list traversal that previously took the lock itself).

SiYuan before v3.7.2 contains a missing authorization vulnerability in the POST /mcp kernel endpoint, which is gated only by a general auth check (model.CheckAuth) with no admin-role or read-only enforcement. This exposes 31 MCP tools, including a file tool with list/read/write/delete/rename/copy actions across the entire workspace. When the Publish server is enabled in anonymous mode (Conf.Publish.Enable=true and Conf.Publish.Auth.Enable=false), the Publish reverse proxy attaches an anonymous RoleReader JWT to proxied requests, allowing a remote unauthenticated attacker to reach /mcp. The attacker can read conf/conf.json to extract accessAuthCode, api.token, and cookieKey in plaintext, write arbitrary files in the workspace, and plant a plugin into data/plugins/ that executes with nodeIntegration:true and no contextIsolation on the next desktop launch, leading to administrator takeover.

OpenRemote before 1.26.2 contains an authentication bypass vulnerability in the console registration API that allows unauthenticated attackers to update existing console assets by supplying a known asset identifier. Attackers can overwrite push notification tokens and console metadata without authentication or ownership validation, redirecting notifications or denying delivery to legitimate consoles.

ImageMagick before 7.1.2-27 contains a memory leak vulnerability in the magick command-line interface when invalid options are provided. Attackers can trigger memory exhaustion by repeatedly supplying malformed command-line arguments to consume system resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/hyperv: validate VMBus packet size in receive callback<br /> <br /> hyperv_receive_sub() reads msg-&gt;vid_hdr.type and dispatches into one<br /> of four message-type branches without knowing how many bytes the host<br /> wrote into hv-&gt;recv_buf. The completion path then runs<br /> memcpy(hv-&gt;init_buf, msg, VMBUS_MAX_PACKET_SIZE), so the consumer that<br /> wakes on wait_for_completion_timeout() can read up to 16 KiB of<br /> residue from a prior message as if it were the response payload.<br /> <br /> Pass bytes_recvd into hyperv_receive_sub() and reject any packet that<br /> does not cover the pipe + synthvid header. A single switch on<br /> msg-&gt;vid_hdr.type then computes the type-specific payload size: the<br /> three completion-driving types (SYNTHVID_VERSION_RESPONSE,<br /> SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) fall through<br /> to a shared exit that requires that size before memcpy/complete, while<br /> SYNTHVID_FEATURE_CHANGE validates its own payload and returns before<br /> reading is_dirt_needed. Unknown types are dropped.<br /> <br /> SYNTHVID_RESOLUTION_RESPONSE is variable length: the host fills<br /> resolution_count entries, not the full SYNTHVID_MAX_RESOLUTION_COUNT<br /> array. Validate the fixed prefix first so resolution_count can be<br /> read, bound it against the array, then require only the count-sized<br /> array, so the shorter responses the host actually sends are accepted.<br /> <br /> Only run the sub-handler when vmbus_recvpacket() returned success. The<br /> memcpy length is bytes_recvd, which is bounded by VMBUS_MAX_PACKET_SIZE<br /> only on a successful receive; on -ENOBUFS vmbus_recvpacket() instead<br /> reports the required length, which can exceed hv-&gt;recv_buf, so copying<br /> bytes_recvd would read and write past the 16 KiB buffers. Gating on the<br /> success return keeps the copy bounded. The nonzero-return path is itself<br /> a malformed-message case and is now logged rather than silently skipped;<br /> channel recovery is not attempted.<br /> <br /> Rejected packets are reported via drm_err_ratelimited() rather than<br /> silently dropped, matching the CoCo-hardened pattern in<br /> hv_kvp_onchannelcallback().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: samsung: Remove redundant port lock acquisition in rx helpers<br /> <br /> Sashiko identified a deadlock when the console flow is engaged [1].<br /> <br /> When console flow control is enabled (UPF_CONS_FLOW),<br /> s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and<br /> s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable().<br /> <br /> The serial core framework invokes the .stop_tx() and .start_tx()<br /> callbacks with the port-&gt;lock spinlock already held. Furthermore, all<br /> internal driver paths that invoke stop_tx (such as the DMA TX<br /> completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ<br /> handler s3c24xx_serial_tx_irq()) also acquire port-&gt;lock prior to<br /> calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the<br /> serial core).<br /> <br /> However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable()<br /> unconditionally attempt to acquire port-&gt;lock again using<br /> uart_port_lock_irqsave(). Since spinlocks are not recursive, this<br /> causes a deadlock on the same CPU when console flow control is engaged.<br /> <br /> Remove the redundant lock acquisition from both rx helper functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - remove unused character device and IOCTLs<br /> <br /> The QAT driver exposes a character device (qat_adf_ctl) with IOCTLs<br /> for device configuration, start, stop, status query and enumeration.<br /> These IOCTLs are not part of any public uAPI header and have no known<br /> in-tree or out-of-tree users. Device lifecycle is already managed via<br /> sysfs.<br /> <br /> The ioctl interface also increases the attack surface and is the<br /> subject of a number of bug reports.<br /> <br /> Remove the character device, the IOCTL definitions, and the related<br /> data structures (adf_dev_status_info, adf_user_cfg_key_val,<br /> adf_user_cfg_section, adf_user_cfg_ctl_data). Drop the now-unused<br /> adf_cfg_user.h header and strip adf_ctl_drv.c down to the minimal<br /> module_init/module_exit hooks for workqueue, AER, and crypto/compression<br /> algorithm registration.<br /> <br /> Clean up leftover dead code that was only reachable from the removed<br /> IOCTL paths: adf_cfg_del_all(), adf_devmgr_verify_id(),<br /> adf_devmgr_get_num_dev(), adf_devmgr_get_dev_by_id(),<br /> adf_get_vf_real_id() and the unused ADF_CFG macros.<br /> <br /> Additionally, drop the entry associated to QAT IOCTLs in<br /> ioctl-number.rst.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix out-of-bounds access for twsk in tcp_ao_established_key().<br /> <br /> lockdep_sock_is_held() was added in tcp_ao_established_key()<br /> by the cited commit.<br /> <br /> It can be called from tcp_v[46]_timewait_ack() with twsk.<br /> <br /> Since it does not have sk-&gt;sk_lock, the lockdep annotation<br /> results in out-of-bound access.<br /> <br /> $ pahole -C tcp_timewait_sock vmlinux | grep size<br /> /* size: 288, cachelines: 5, members: 8 */<br /> $ pahole -C sock vmlinux | grep sk_lock<br /> socket_lock_t sk_lock; /* 440 192 */<br /> <br /> Let&amp;#39;s not use lockdep_sock_is_held() for TCP_TIME_WAIT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix infinite loop in layout state revocation<br /> <br /> find_one_sb_stid() skips stids whose sc_status is non-zero, but the<br /> SC_TYPE_LAYOUT case in nfsd4_revoke_states() never sets sc_status<br /> before calling nfsd4_close_layout(). The retry loop therefore finds<br /> the same layout stid on every iteration, hanging the revoker<br /> indefinitely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies<br /> <br /> The register-based PARTITION_INFO_GET path trusted the firmware-provided<br /> indices when copying partition descriptors into the caller buffer.<br /> Reject inconsistent counts or index progressions so the copy loop cannot<br /> write past the allocated array.<br /> <br /> (fixed cur_idx when exactly one descriptor in the first fragment)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: meson: amlogic-a4: fix deadlock issue<br /> <br /> Accessing the pinconf-pins sysfs node may deadlock.<br /> <br /> pinconf_pins_show() holds pctldev-&gt;mutex, and the platform driver<br /> calls pinctrl_find_gpio_range_from_pin(), which tries to acquire<br /> the same mutex again, leading to a deadlock.<br /> <br /> Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix eswitch mode block underflow on IPsec acquire SA<br /> <br /> mlx5e_xfrm_add_state() handles acquire-flow temporary SAs by allocating<br /> software state and skipping hardware offload setup.<br /> <br /> That path jumps to the common success label before taking the eswitch mode<br /> block. After tunnel-mode validation was moved earlier, the common success<br /> label unconditionally calls mlx5_eswitch_unblock_mode(). For acquire SAs,<br /> this decrements esw-&gt;offloads.num_block_mode without a matching increment.<br /> <br /> Return directly after installing the acquire SA offload handle, so only the<br /> paths that successfully called mlx5_eswitch_block_mode() call the matching<br /> unblock.