Vulnerabilities

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 /> 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 /> 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 /> 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 /> dmaengine: idxd: Fix not releasing workqueue on .release()<br /> <br /> The workqueue associated with an DSA/IAA device is not released when<br /> the object is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: always drain queued discard work in ext4_mb_release()<br /> <br /> While reviewing recent ext4 patch[1], Sashiko raised the following<br /> concern[2]:<br /> <br /> &gt; If the filesystem is initially mounted with the discard option,<br /> &gt; deleting files will populate sbi-&gt;s_discard_list and queue<br /> &gt; s_discard_work. If it is then remounted with nodiscard, the<br /> &gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is<br /> &gt; neither cancelled nor flushed.<br /> <br /> [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/<br /> [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev<br /> <br /> The concern was valid, but it had nothing to do with the patch[1].<br /> One of the problems with Sashiko in its current (early) form is that<br /> it will detect pre-existing issues and report it as a problem with the<br /> patch that it is reviewing.<br /> <br /> In practice, it would be hard to hit deliberately (unless you are a<br /> malicious syzkaller fuzzer), since it would involve mounting the file<br /> system with -o discard, and then deleting a large number of files,<br /> remounting the file system with -o nodiscard, and then immediately<br /> unmounting the file system before the queued discard work has a change<br /> to drain on its own.<br /> <br /> Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this<br /> concern when analyzing future patches to mballoc.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths<br /> <br /> During code review, Joseph found that ext4_fc_replay_inode() calls<br /> ext4_get_fc_inode_loc() to get the inode location, which holds a<br /> reference to iloc.bh that must be released via brelse().<br /> <br /> However, several error paths jump to the &amp;#39;out&amp;#39; label without<br /> releasing iloc.bh:<br /> <br /> - ext4_handle_dirty_metadata() failure<br /> - sync_dirty_buffer() failure<br /> - ext4_mark_inode_used() failure<br /> - ext4_iget() failure<br /> <br /> Fix this by introducing an &amp;#39;out_brelse&amp;#39; label placed just before<br /> the existing &amp;#39;out&amp;#39; label to ensure iloc.bh is always released.<br /> <br /> Additionally, make ext4_fc_replay_inode() propagate errors<br /> properly instead of always returning 0.

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.