Vulnerabilities

A security flaw has been discovered in Grandstream GXP1625 1.0.7.4. The impacted element is an unknown function of the file /cgi-bin/api.values.post of the component Network Status Page. Performing manipulation of the argument vpn_ip results in basic cross site scripting. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was identified in Yonyou U8 Cloud 5.0/5.0sp/5.1/5.1sp. The affected element is an unknown function of the file nc/pubitf/erm/mobile/appservice/AppServletService.class. Such manipulation of the argument usercode leads to sql injection. The attack may be launched remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was determined in SGAI Space1 NAS N1211DS up to 1.0.915. Impacted is the function RENAME_FILE/OPERATE_FILE/NGNIX_UPLOAD of the file /cgi-bin/JSONAPI of the component gsaiagent. This manipulation causes command injection. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was found in SGAI Space1 NAS N1211DS up to 1.0.915. This issue affects the function GET_FACTORY_INFO/GET_USER_INFO of the file /cgi-bin/JSONAPI of the component gsaiagent. The manipulation results in unprotected storage of credentials. The attack can be launched remotely. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability has been found in Sobey Media Convergence System 2.0/2.1. This vulnerability affects unknown code of the file /sobey-mchEditor/watermark/upload. The manipulation of the argument File leads to path traversal. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices<br /> <br /> Previously, APU platforms (and other scenarios with uninitialized VRAM managers)<br /> triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root<br /> cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,<br /> but that `man-&gt;bdev` (the backing device pointer within the manager) remains<br /> uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully<br /> set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to<br /> acquire `man-&gt;bdev-&gt;lru_lock`, it dereferences the NULL `man-&gt;bdev`, leading to<br /> a kernel OOPS.<br /> <br /> 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in<br /> `amdgpu_cs_get_threshold_for_moves()` to include a check for<br /> `ttm_resource_manager_used()`. If the manager is not used (uninitialized<br /> `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific<br /> logic that would trigger the NULL dereference.<br /> <br /> 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info<br /> reporting to use a conditional: if the manager is used, return the real VRAM<br /> usage; otherwise, return 0. This avoids accessing `man-&gt;bdev` when it is<br /> NULL.<br /> <br /> 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function)<br /> data write path. Use `ttm_resource_manager_used()` to check validity: if the<br /> manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set<br /> `fb_usage` to 0 (APUs have no discrete framebuffer to report).<br /> <br /> This approach is more robust than APU-specific checks because it:<br /> - Works for all scenarios where the VRAM manager is uninitialized (not just APUs),<br /> - Aligns with TTM&amp;#39;s design by using its native helper function,<br /> - Preserves correct behavior for discrete GPUs (which have fully initialized<br /> `man-&gt;bdev` and pass the `ttm_resource_manager_used()` check).<br /> <br /> v4: use ttm_resource_manager_used(&amp;adev-&gt;mman.vram_mgr.manager) instead of checking the adev-&gt;gmc.is_app_apu flag (Christian)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM<br /> <br /> Otherwise accessing them can cause a crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto<br /> <br /> syzbot reported a possible shift-out-of-bounds [1]<br /> <br /> Blamed commit added rto_alpha_max and rto_beta_max set to 1000.<br /> <br /> It is unclear if some sctp users are setting very large rto_alpha<br /> and/or rto_beta.<br /> <br /> In order to prevent user regression, perform the test at run time.<br /> <br /> Also add READ_ONCE() annotations as sysctl values can change under us.<br /> <br /> [1]<br /> <br /> UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41<br /> shift exponent 64 is too large for 32-bit type &amp;#39;unsigned int&amp;#39;<br /> CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120<br /> ubsan_epilogue lib/ubsan.c:233 [inline]<br /> __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494<br /> sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509<br /> sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502<br /> sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338<br /> sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline]<br /> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: 6lowpan: reset link-local header on ipv6 recv path<br /> <br /> Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local<br /> header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW<br /> <br /> Add missing skb_reset_mac_header() for uncompressed ipv6 RX path.<br /> <br /> For the compressed one, it is done in lowpan_header_decompress().<br /> <br /> Log: (BlueZ 6lowpan-tester Client Recv Raw - Success)<br /> ------<br /> kernel BUG at net/core/skbuff.c:212!<br /> Call Trace:<br /> <br /> ...<br /> packet_rcv (net/packet/af_packet.c:2152)<br /> ...<br /> <br /> __local_bh_enable_ip (kernel/softirq.c:407)<br /> netif_rx (net/core/dev.c:5648)<br /> chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359)<br /> ------

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF<br /> <br /> There is a KASAN: slab-use-after-free read in btusb_disconnect().<br /> Calling "usb_driver_release_interface(&amp;btusb_driver, data-&gt;intf)" will<br /> free the btusb data associated with the interface. The same data is<br /> then used later in the function, hence the UAF.<br /> <br /> Fix by moving the accesses to btusb data to before the data is free&amp;#39;d.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: cancel mesh send timer when hdev removed<br /> <br /> mesh_send_done timer is not canceled when hdev is removed, which causes<br /> crash if the timer triggers after hdev is gone.<br /> <br /> Cancel the timer when MGMT removes the hdev, like other MGMT timers.<br /> <br /> Should fix the BUG: sporadically seen by BlueZ test bot<br /> (in "Mesh - Send cancel - 1" test).<br /> <br /> Log:<br /> ------<br /> BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0<br /> ...<br /> Freed by task 36:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3a/0x60<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x103/0x500<br /> device_release+0x9a/0x210<br /> kobject_put+0x100/0x1e0<br /> vhci_release+0x18b/0x240<br /> ------

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/server: fix possible refcount leak in smb2_sess_setup()<br /> <br /> Reference count of ksmbd_session will leak when session need reconnect.<br /> Fix this by adding the missing ksmbd_user_session_put().