Vulnerabilities

An issue in H3C Magic M Device M2V100R006 allows a remote attacker to execute arbitrary code via the default password

An issue in TOTOLINK Wi-Fi 6 Router Series Device X2000R-Gh-V2.0.0 allows a remote attacker to execute arbitrary code via the default password

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Duplicate SPI Handling<br /> <br /> The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI<br /> Netlink message, which triggers the kernel function xfrm_alloc_spi().<br /> This function is expected to ensure uniqueness of the Security Parameter<br /> Index (SPI) for inbound Security Associations (SAs). However, it can<br /> return success even when the requested SPI is already in use, leading<br /> to duplicate SPIs assigned to multiple inbound SAs, differentiated<br /> only by their destination addresses.<br /> <br /> This behavior causes inconsistencies during SPI lookups for inbound packets.<br /> Since the lookup may return an arbitrary SA among those with the same SPI,<br /> packet processing can fail, resulting in packet drops.<br /> <br /> According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA<br /> is uniquely identified by the SPI and optionally protocol.<br /> <br /> Reproducing the Issue Reliably:<br /> To consistently reproduce the problem, restrict the available SPI range in<br /> charon.conf : spi_min = 0x10000000 spi_max = 0x10000002<br /> This limits the system to only 2 usable SPI values.<br /> Next, create more than 2 Child SA. each using unique pair of src/dst address.<br /> As soon as the 3rd Child SA is initiated, it will be assigned a duplicate<br /> SPI, since the SPI pool is already exhausted.<br /> With a narrow SPI range, the issue is consistently reproducible.<br /> With a broader/default range, it becomes rare and unpredictable.<br /> <br /> Current implementation:<br /> xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.<br /> So if two SAs have the same SPI but different destination addresses, then<br /> they will:<br /> a. Hash into different buckets<br /> b. Be stored in different linked lists (byspi + h)<br /> c. Not be seen in the same hlist_for_each_entry_rcu() iteration.<br /> As a result, the lookup will result in NULL and kernel allows that Duplicate SPI<br /> <br /> Proposed Change:<br /> xfrm_state_lookup_spi_proto() does a truly global search - across all states,<br /> regardless of hash bucket and matches SPI and proto.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

File Upload vulnerability in SueamCMS v.0.1.2 allows a remote attacker to execute arbitrary code via the lack of filtering.

An issue in H3C Device R365V300R004 allows a remote attacker to execute arbitrary code via the default password. NOTE: the Supplier&amp;#39;s position is that their "product lines enforce or clearly prompt users to change any initial credentials upon first use. At most, this would be a case of misconfiguration if an administrator deliberately ignored the prompts, which is outside the scope of CVE definitions."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix the setting of capabilities when automounting a new filesystem<br /> <br /> Capabilities cannot be inherited when we cross into a new filesystem.<br /> They need to be reset to the minimal defaults, and then probed for<br /> again.

A vulnerability was detected in iteachyou Dreamer CMS up to 4.1.3.2. This issue affects some unknown processing of the file /admin/user/updatePwd. Performing manipulation results in weak password requirements. Remote exploitation of the attack is possible. A high degree of complexity is needed for the attack. The exploitability is assessed as difficult. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: Always split write BIOs to zoned device limits<br /> <br /> Any zoned DM target that requires zone append emulation will use the<br /> block layer zone write plugging. In such case, DM target drivers must<br /> not split BIOs using dm_accept_partial_bio() as doing so can potentially<br /> lead to deadlocks with queue freeze operations. Regular write operations<br /> used to emulate zone append operations also cannot be split by the<br /> target driver as that would result in an invalid writen sector value<br /> return using the BIO sector.<br /> <br /> In order for zoned DM target drivers to avoid such incorrect BIO<br /> splitting, we must ensure that large BIOs are split before being passed<br /> to the map() function of the target, thus guaranteeing that the<br /> limits for the mapped device are not exceeded.<br /> <br /> dm-crypt and dm-flakey are the only target drivers supporting zoned<br /> devices and using dm_accept_partial_bio().<br /> <br /> In the case of dm-crypt, this function is used to split BIOs to the<br /> internal max_write_size limit (which will be suppressed in a different<br /> patch). However, since crypt_alloc_buffer() uses a bioset allowing only<br /> up to BIO_MAX_VECS (256) vectors in a BIO. The dm-crypt device<br /> max_segments limit, which is not set and so default to BLK_MAX_SEGMENTS<br /> (128), must thus be respected and write BIOs split accordingly.<br /> <br /> In the case of dm-flakey, since zone append emulation is not required,<br /> the block layer zone write plugging is not used and no splitting of BIOs<br /> required.<br /> <br /> Modify the function dm_zone_bio_needs_split() to use the block layer<br /> helper function bio_needs_zone_write_plugging() to force a call to<br /> bio_split_to_limits() in dm_split_and_process_bio(). This allows DM<br /> target drivers to avoid using dm_accept_partial_bio() for write<br /> operations on zoned DM devices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/memmap: cast nr_pages to size_t before shifting<br /> <br /> If the allocated size exceeds UINT_MAX, then it&amp;#39;s necessary to cast<br /> the mr-&gt;nr_pages value to size_t to prevent it from overflowing. In<br /> practice this isn&amp;#39;t much of a concern as the required memory size will<br /> have been validated upfront, and accounted to the user. And &gt; 4GB sizes<br /> will be necessary to make the lack of a cast a problem, which greatly<br /> exceeds normal user locked_vm settings that are generally in the kb to<br /> mb range. However, if root is used, then accounting isn&amp;#39;t done, and<br /> then it&amp;#39;s possible to hit this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lapbether: ignore ops-locked netdevs<br /> <br /> Syzkaller managed to trigger lock dependency in xsk_notify via<br /> register_netdevice. As discussed in [0], using register_netdevice<br /> in the notifiers is problematic so skip adding lapbeth for ops-locked<br /> devices.<br /> <br /> xsk_notifier+0xa4/0x280 net/xdp/xsk.c:1645<br /> notifier_call_chain+0xbc/0x410 kernel/notifier.c:85<br /> call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230<br /> call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2282 [inline]<br /> unregister_netdevice_many_notify+0xf9d/0x2700 net/core/dev.c:12077<br /> unregister_netdevice_many net/core/dev.c:12140 [inline]<br /> unregister_netdevice_queue+0x305/0x3f0 net/core/dev.c:11984<br /> register_netdevice+0x18f1/0x2270 net/core/dev.c:11149<br /> lapbeth_new_device drivers/net/wan/lapbether.c:420 [inline]<br /> lapbeth_device_event+0x5b1/0xbe0 drivers/net/wan/lapbether.c:462<br /> notifier_call_chain+0xbc/0x410 kernel/notifier.c:85<br /> call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230<br /> call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2282 [inline]<br /> __dev_notify_flags+0x12c/0x2e0 net/core/dev.c:9497<br /> netif_change_flags+0x108/0x160 net/core/dev.c:9526<br /> dev_change_flags+0xba/0x250 net/core/dev_api.c:68<br /> devinet_ioctl+0x11d5/0x1f50 net/ipv4/devinet.c:1200<br /> inet_ioctl+0x3a7/0x3f0 net/ipv4/af_inet.c:1001<br /> <br /> 0: https://lore.kernel.org/netdev/20250625140357.6203d0af@kernel.org/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: tegra: Use I/O memcpy to write to IRAM<br /> <br /> Kasan crashes the kernel trying to check boundaries when using the<br /> normal memcpy.