Vulnerabilities

A vulnerability was detected in chatchat-space Langchain-Chatchat up to 0.3.1.3. This vulnerability affects the function files/list_files/retrieve_file/retrieve_file_content/delete_file of the file libs/chatchat-server/chatchat/server/api_server/openai_routes.py of the component Compatible File Service. The manipulation results in missing authentication. The attacker must have access to the local network to execute the attack. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A flaw has been found in chatchat-space Langchain-Chatchat up to 0.3.1.3. This issue affects the function PIL.Image.tobytes of the file libs/chatchat-server/chatchat/webui_pages/dialogue/dialogue.py of the component Vision Chat Paste Image Handler. This manipulation of the argument paste_image.image_data causes use of weak hash. The attacker needs to be present on the local network. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability has been found in chatchat-space Langchain-Chatchat up to 0.3.1.3. Impacted is the function files of the file libs/chatchat-server/chatchat/server/api_server/openai_routes.py of the component OpenAI-Compatible File Upload API. Such manipulation of the argument file.filename leads to time-of-check time-of-use. Access to the local network is required for this attack to succeed. The attack requires a high level of complexity. The exploitability is considered difficult. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A hidden console command is vulnerable to command injection<br /> flaw when control characters are passed to its second argument. <br /> <br /> A third party researcher Eugene Lim had discovered vulnerability<br /> in the way console command passes to a popen function call. Attackers with<br /> authenticated access to SSH console of Crestron devices may use to run<br /> underlying OS commands.

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14.<br /> `django.middleware.cache.UpdateCacheMiddleware` erroneously caches requests where the `Vary` header contained an asterisk (`&amp;#39;*&amp;#39;`). This can lead to private data being stored and served.<br /> Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.<br /> Django would like to thank Ahmad Sadeddin for reporting this issue.

In Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10, inadequate path normalization in the Submodel HTTP API allows an unauthenticated remote attacker to perform a path traversal attack. By supplying a maliciously crafted fileName parameter during a file upload operation, an attacker can bypass intended storage boundaries and write arbitrary files to any location on the host filesystem accessible by the Java process. This can lead to Remote Code Execution (RCE) and complete system compromise.

In Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10, the Operation Delegation feature fails to validate the destination URI of delegated requests. An unauthenticated remote attacker can exploit this design flaw to force the BaSyx server to execute blind HTTP POST requests to arbitrary internal or external targets. This allows an attacker to bypass network segmentation and pivot into isolated internal IT/OT infrastructure or target Cloud Metadata services (IMDS).

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14.<br /> ASGI requests with a missing or understated `Content-Length` header can bypass the `FILE_UPLOAD_MAX_MEMORY_SIZE` limit, potentially loading large files into memory and causing service degradation.<br /> <br /> As a reminder, Django expects a limit to be configured at the web server level rather than solely relying on `FILE_UPLOAD_MAX_MEMORY_SIZE`.<br /> Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.<br /> Django would like to thank Kyle Agronick for reporting this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()<br /> <br /> There&amp;#39;s issue as follows:<br /> ...<br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): error count since last fsck: 1<br /> EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760<br /> EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760<br /> ...<br /> <br /> According to the log analysis, blocks are always requested from the<br /> corrupted block group. This may happen as follows:<br /> ext4_mb_find_by_goal<br /> ext4_mb_load_buddy<br /> ext4_mb_load_buddy_gfp<br /> ext4_mb_init_cache<br /> ext4_read_block_bitmap_nowait<br /> ext4_wait_block_bitmap<br /> ext4_validate_block_bitmap<br /> if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))<br /> return -EFSCORRUPTED; // There&amp;#39;s no logs.<br /> if (err)<br /> return err; // Will return error<br /> ext4_lock_group(ac-&gt;ac_sb, group);<br /> if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-&gt;bd_info))) // Unreachable<br /> goto out;<br /> <br /> After commit 9008a58e5dce ("ext4: make the bitmap read routines return<br /> real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group<br /> as corrupt on block bitmap error") is no real solution for allocating<br /> blocks from corrupted block groups. This is because if<br /> &amp;#39;EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-&gt;bd_info)&amp;#39; is true, then<br /> &amp;#39;ext4_mb_load_buddy()&amp;#39; may return an error. This means that the block<br /> allocation will fail.<br /> Therefore, check block group if corrupted when ext4_mb_load_buddy()<br /> returns error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_ll: Fix firmware leak on error path<br /> <br /> Smatch reports:<br /> <br /> drivers/bluetooth/hci_ll.c:587 download_firmware() warn:<br /> &amp;#39;fw&amp;#39; from request_firmware() not released on lines: 544.<br /> <br /> In download_firmware(), if request_firmware() succeeds but the returned<br /> firmware content is invalid (no data or zero size), the function returns<br /> without releasing the firmware, resulting in a resource leak.<br /> <br /> Fix this by calling release_firmware() before returning when<br /> request_firmware() succeeded but the firmware content is invalid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reset register ID for BPF_END value tracking<br /> <br /> When a register undergoes a BPF_END (byte swap) operation, its scalar<br /> value is mutated in-place. If this register previously shared a scalar ID<br /> with another register (e.g., after an `r1 = r0` assignment), this tie must<br /> be broken.<br /> <br /> Currently, the verifier misses resetting `dst_reg-&gt;id` to 0 for BPF_END.<br /> Consequently, if a conditional jump checks the swapped register, the<br /> verifier incorrectly propagates the learned bounds to the linked register,<br /> leading to false confidence in the linked register&amp;#39;s value and potentially<br /> allowing out-of-bounds memory accesses.<br /> <br /> Fix this by explicitly resetting `dst_reg-&gt;id` to 0 in the BPF_END case<br /> to break the scalar tie, similar to how BPF_NEG handles it via<br /> `__mark_reg_known`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dcache: Limit the minimal number of bucket to two<br /> <br /> There is an OOB read problem on dentry_hashtable when user sets<br /> &amp;#39;dhash_entries=1&amp;#39;:<br /> BUG: unable to handle page fault for address: ffff888b30b774b0<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> RIP: 0010:__d_lookup+0x56/0x120<br /> Call Trace:<br /> d_lookup.cold+0x16/0x5d<br /> lookup_dcache+0x27/0xf0<br /> lookup_one_qstr_excl+0x2a/0x180<br /> start_dirop+0x55/0xa0<br /> simple_start_creating+0x8d/0xa0<br /> debugfs_start_creating+0x8c/0x180<br /> debugfs_create_dir+0x1d/0x1c0<br /> pinctrl_init+0x6d/0x140<br /> do_one_initcall+0x6d/0x3d0<br /> kernel_init_freeable+0x39f/0x460<br /> kernel_init+0x2a/0x260<br /> <br /> There will be only one bucket in dentry_hashtable when dhash_entries is<br /> set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,<br /> following process will access more than one buckets(which memory region<br /> is not allocated) in dentry_hashtable:<br /> d_lookup<br /> b = d_hash(hash)<br /> dentry_hashtable + ((u32)hashlen &gt;&gt; d_hash_shift)<br /> // The C standard defines the behavior of right shift amounts<br /> // exceeding the bit width of the operand as undefined. The<br /> // result of &amp;#39;(u32)hashlen &gt;&gt; d_hash_shift&amp;#39; becomes &amp;#39;hashlen&amp;#39;,<br /> // so &amp;#39;b&amp;#39; will point to an unallocated memory region.<br /> hlist_bl_for_each_entry_rcu(b)<br /> hlist_bl_first_rcu(head)<br /> h-&gt;first // read OOB!<br /> <br /> Fix it by limiting the minimal number of dentry_hashtable bucket to two,<br /> so that &amp;#39;d_hash_shift&amp;#39; won&amp;#39;t exceeds the bit width of type u32.