Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: platform_get_irq_byname() returns an int<br /> <br /> platform_get_irq_byname() will return a negative value if an error<br /> happens, so it should be checked and not just passed directly into<br /> devm_request_threaded_irq() hoping all will be ok.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86-64: rename misleadingly named &amp;#39;__copy_user_nocache()&amp;#39; function<br /> <br /> This function was a masterclass in bad naming, for various historical<br /> reasons.<br /> <br /> It claimed to be a non-cached user copy. It is literally _neither_ of<br /> those things. It&amp;#39;s a specialty memory copy routine that uses<br /> non-temporal stores for the destination (but not the source), and that<br /> does exception handling for both source and destination accesses.<br /> <br /> Also note that while it works for unaligned targets, any unaligned parts<br /> (whether at beginning or end) will not use non-temporal stores, since<br /> only words and quadwords can be non-temporal on x86.<br /> <br /> The exception handling means that it _can_ be used for user space<br /> accesses, but not on its own - it needs all the normal "start user space<br /> access" logic around it.<br /> <br /> But typically the user space access would be the source, not the<br /> non-temporal destination. That was the original intention of this,<br /> where the destination was some fragile persistent memory target that<br /> needed non-temporal stores in order to catch machine check exceptions<br /> synchronously and deal with them gracefully.<br /> <br /> Thus that non-descriptive name: one use case was to copy from user space<br /> into a non-cached kernel buffer. However, the existing users are a mix<br /> of that intended use-case, and a couple of random drivers that just did<br /> this as a performance tweak.<br /> <br /> Some of those random drivers then actively misused the user copying<br /> version (with STAC/CLAC and all) to do kernel copies without ever even<br /> caring about the exception handling, _just_ for the non-temporal<br /> destination.<br /> <br /> Rename it as a first small step to actually make it halfway sane, and<br /> change the prototype to be more normal: it doesn&amp;#39;t take a user pointer<br /> unless the caller has done the proper conversion, and the argument size<br /> is the full size_t (it still won&amp;#39;t actually copy more than 4GB in one<br /> go, but there&amp;#39;s also no reason to silently truncate the size argument in<br /> the caller).<br /> <br /> Finally, use this now sanely named function in the NTB code, which<br /> mis-used a user copy version (with STAC/CLAC and all) of this interface<br /> despite it not actually being a user copy at all.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: drop pending enqueued packets on removal<br /> <br /> Packets sitting in nfqueue might hold a reference to:<br /> <br /> - templates that specify the conntrack zone, because a percpu area is<br /> used and module removal is possible.<br /> - conntrack timeout policies and helper, where object removal leave<br /> a stale reference.<br /> <br /> Since these objects can just go away, drop enqueued packets to avoid<br /> stale reference to them.<br /> <br /> If there is a need for finer grain removal, this logic can be revisited<br /> to make selective packet drop upon dependencies.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: Fix TX deadlock when using DMA<br /> <br /> `dmaengine_terminate_async` does not guarantee that the<br /> `__dma_tx_complete` callback will run. The callback is currently the<br /> only place where `dma-&gt;tx_running` gets cleared. If the transaction is<br /> canceled and the callback never runs, then `dma-&gt;tx_running` will never<br /> get cleared and we will never schedule new TX DMA transactions again.<br /> <br /> This change makes it so we clear `dma-&gt;tx_running` after we terminate<br /> the DMA transaction. This is "safe" because `serial8250_tx_dma_flush`<br /> is holding the UART port lock. The first thing the callback does is also<br /> grab the UART port lock, so access to `dma-&gt;tx_running` is serialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()<br /> <br /> l2cap_ecred_reconf_rsp() casts the incoming data to struct<br /> l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with<br /> result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes<br /> with result at offset 0).<br /> <br /> This causes two problems:<br /> <br /> - The sizeof(*rsp) length check requires 8 bytes instead of the<br /> correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected<br /> with -EPROTO.<br /> <br /> - rsp-&gt;result reads from offset 6 instead of offset 0, returning<br /> wrong data when the packet is large enough to pass the check.<br /> <br /> Fix by using the correct type. Also pass the already byte-swapped<br /> result variable to BT_DBG instead of the raw __le16 field.