Vulnerabilities

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.

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

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: avoid possible overflow for chunk_sectors check in blk_stack_limits()<br /> <br /> In blk_stack_limits(), we check that the t-&gt;chunk_sectors value is a<br /> multiple of the t-&gt;physical_block_size value.<br /> <br /> However, by finding the chunk_sectors value in bytes, we may overflow<br /> the unsigned int which holds chunk_sectors, so change the check to be<br /> based on sectors.

Viber Desktop 25.6.0 is vulnerable to HTML Injection via the text parameter of the message compose/forward interface

A security flaw has been discovered in JeecgBoot up to 3.8.2. Affected by this issue is some unknown functionality of the file /sys/tenant/exportLog of the component Tenant Log Export. The manipulation results in improper authorization. The attack can be launched remotely. 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.

Langchaingo supports the use of jinja2 syntax when parsing prompts, which is in turn parsed using the gonja library v1.5.3.<br /> Gonja supports include and extends syntax to read files, which leads to a server side template injection vulnerability within langchaingo, allowing an attacker to insert a statement into a prompt to read the "etc/passwd" file.

Hono is a Web application framework that provides support for any JavaScript runtime. In versions prior to 4.9.7, a flaw in the `bodyLimit` middleware could allow bypassing the configured request body size limit when conflicting HTTP headers were present. The middleware previously prioritized the `Content-Length` header even when a `Transfer-Encoding: chunked` header was also included. According to the HTTP specification, `Content-Length` must be ignored in such cases. This discrepancy could allow oversized request bodies to bypass the configured limit. Most standards-compliant runtimes and reverse proxies may reject such malformed requests with `400 Bad Request`, so the practical impact depends on the runtime and deployment environment. If body size limits are used as a safeguard against large or malicious requests, this flaw could allow attackers to send oversized request bodies. The primary risk is denial of service (DoS) due to excessive memory or CPU consumption when handling very large requests. The implementation has been updated to align with the HTTP specification, ensuring that `Transfer-Encoding` takes precedence over `Content-Length`. The issue is fixed in Hono v4.9.7, and all users should upgrade immediately.

httpsig-rs is a Rust implementation of IETF RFC 9421 http message signatures. Prior to version 0.0.19, the HMAC signature comparison is not timing-safe. This makes anyone who uses HS256 signature verification vulnerable to a timing attack that allows the attacker to forge a signature. Version 0.0.19 fixes the issue.