Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: renesas: Fix memory leak in renesas_i3c_i3c_xfers()<br /> <br /> The xfer structure allocated by renesas_i3c_alloc_xfer() was never freed<br /> in the renesas_i3c_i3c_xfers() function. Use the __free(kfree) cleanup<br /> attribute to automatically free the memory when the variable goes out of<br /> scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()<br /> <br /> When a compressed or sparse attribute has its clusters frame-aligned,<br /> vcn is rounded down to the frame start using cmask, which can result<br /> in vcn != vcn0. In this case, vcn and vcn0 may reside in different<br /> attribute segments.<br /> <br /> The code already handles the case where vcn is in a different segment<br /> by loading its runs before allocation. However, it fails to load runs<br /> for vcn0 when vcn0 resides in a different segment than vcn. This causes<br /> run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was<br /> never loaded into the in-memory run list, triggering the WARN_ON(1).<br /> <br /> Fix this by adding a missing check for vcn0 after the existing vcn<br /> segment check. If vcn0 falls outside the current segment range<br /> [svcn, evcn1), find and load the attribute segment containing vcn0<br /> before performing the run lookup.<br /> <br /> The following scenario triggers the bug:<br /> attr_data_get_block_locked()<br /> vcn = vcn0 &amp; cmask

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: spacemit: ccu_mix: fix inverted condition in ccu_mix_trigger_fc()<br /> <br /> Fix inverted condition that skips frequency change trigger,<br /> causing kernel panics during cpufreq scaling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: avoid reading already updated pages during GC<br /> <br /> We found the following issue during fuzz testing:<br /> <br /> page: refcount:3 mapcount:0 mapping:00000000b6e89c65 index:0x18b2dc pfn:0x161ba9<br /> memcg:f8ffff800e269c00<br /> aops:f2fs_meta_aops ino:2<br /> flags: 0x52880000000080a9(locked|waiters|uptodate|lru|private|zone=1|kasantag=0x4a)<br /> raw: 52880000000080a9 fffffffec6e17588 fffffffec0ccc088 a7ffff8067063618<br /> raw: 000000000018b2dc 0000000000000009 00000003ffffffff f8ffff800e269c00<br /> page dumped because: VM_BUG_ON_FOLIO(folio_test_uptodate(folio))<br /> page_owner tracks the page as allocated<br /> post_alloc_hook+0x58c/0x5ec<br /> prep_new_page+0x34/0x284<br /> get_page_from_freelist+0x2dcc/0x2e8c<br /> __alloc_pages_noprof+0x280/0x76c<br /> __folio_alloc_noprof+0x18/0xac<br /> __filemap_get_folio+0x6bc/0xdc4<br /> pagecache_get_page+0x3c/0x104<br /> do_garbage_collect+0x5c78/0x77a4<br /> f2fs_gc+0xd74/0x25f0<br /> gc_thread_func+0xb28/0x2930<br /> kthread+0x464/0x5d8<br /> ret_from_fork+0x10/0x20<br /> ------------[ cut here ]------------<br /> kernel BUG at mm/filemap.c:1563!<br /> folio_end_read+0x140/0x168<br /> f2fs_finish_read_bio+0x5c4/0xb80<br /> f2fs_read_end_io+0x64c/0x708<br /> bio_endio+0x85c/0x8c0<br /> blk_update_request+0x690/0x127c<br /> scsi_end_request+0x9c/0xb8c<br /> scsi_io_completion+0xf0/0x250<br /> scsi_finish_command+0x430/0x45c<br /> scsi_complete+0x178/0x6d4<br /> blk_mq_complete_request+0xcc/0x104<br /> scsi_done_internal+0x214/0x454<br /> scsi_done+0x24/0x34<br /> <br /> which is similar to the problem reported by syzbot:<br /> https://syzkaller.appspot.com/bug?extid=3686758660f980b402dc<br /> <br /> This case is consistent with the description in commit 9bf1a3f<br /> ("f2fs: avoid GC causing encrypted file corrupted"):<br /> Page 1 is moved from blkaddr A to blkaddr B by move_data_block, and after<br /> being written it is marked as uptodate. Then, Page 1 is moved from blkaddr<br /> B to blkaddr C, VM_BUG_ON_FOLIO was triggered in the endio initiated by<br /> ra_data_block.<br /> <br /> There is no need to read Page 1 again from blkaddr B, since it has already<br /> been updated. Therefore, avoid initiating I/O in this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix data loss caused by incorrect use of nat_entry flag<br /> <br /> Data loss can occur when fsync is performed on a newly created file<br /> (before any checkpoint has been written) concurrently with a checkpoint<br /> operation. The scenario is as follows:<br /> <br /> create &amp; write &amp; fsync &amp;#39;file A&amp;#39; write checkpoint<br /> - f2fs_do_sync_file // inline inode<br /> - f2fs_write_inode // inode folio is dirty<br /> - f2fs_write_checkpoint<br /> - f2fs_flush_merged_writes<br /> - f2fs_sync_node_pages<br /> - f2fs_flush_nat_entries<br /> - f2fs_fsync_node_pages // no dirty node<br /> - f2fs_need_inode_block_update // return false<br /> SPO and lost &amp;#39;file A&amp;#39;<br /> <br /> f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC<br /> flags for the nat_entry, but this does not mean that the checkpoint has<br /> actually completed successfully. However, f2fs_need_inode_block_update()<br /> checks these flags and incorrectly assumes that the checkpoint has<br /> finished.<br /> <br /> The root cause is that the semantics of IS_CHECKPOINTED and<br /> HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully<br /> completes.<br /> <br /> This patch modifies f2fs_need_inode_block_update() to acquire the<br /> sbi-&gt;node_write lock before reading the nat_entry flags, ensuring that<br /> once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the<br /> checkpoint operation has already completed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: raw: fix use-after-free if write is called after disconnect<br /> <br /> If a user writes to the chardev after disconnect has been called, the<br /> kernel panics with the following trace (with<br /> CONFIG_INIT_ON_FREE_DEFAULT_ON=y):<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000218<br /> ...<br /> Call Trace:<br /> <br /> gb_operation_create_common+0x61/0x180<br /> gb_operation_create_flags+0x28/0xa0<br /> gb_operation_sync_timeout+0x6f/0x100<br /> raw_write+0x7b/0xc7 [gb_raw]<br /> vfs_write+0xcf/0x420<br /> ? task_mm_cid_work+0x136/0x220<br /> ksys_write+0x63/0xe0<br /> do_syscall_64+0xa4/0x290<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Disconnect calls gb_connection_destroy, which ends up freeing the<br /> connection object. When gb_operation_sync is called in the write file<br /> operations, its gets a freed connection as parameter and the kernel<br /> panics.<br /> <br /> The gb_connection_destroy cannot be moved out of the disconnect<br /> function, as the Greybus subsystem expect all connections belonging to a<br /> bundle to be destroyed when disconnect returns.<br /> <br /> To prevent this bug, use a rw lock to synchronize access between write<br /> and disconnect. This guarantees that the write function doesn&amp;#39;t try<br /> to use a disconnected connection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: terminate the cached volume label after UTF-8 conversion<br /> <br /> ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s()<br /> and stores the result in sbi-&gt;volume.label. The converted label is later<br /> exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only<br /> returns the number of bytes written and does not add a trailing NUL.<br /> <br /> If the converted label fills the entire fixed buffer,<br /> ntfs3_label_show() can read past the end of sbi-&gt;volume.label while<br /> looking for a terminator.<br /> <br /> Terminate the cached label explicitly after a successful conversion and<br /> clamp the exact-full case to the last byte of the buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-wmi-sysman: bound enumeration string aggregation<br /> <br /> populate_enum_data() aggregates firmware-provided value-modifier<br /> and possible-value strings into fixed 512-byte struct members.<br /> The current code bounds each individual source string but then<br /> appends every string and separator with raw strcat() and no<br /> remaining-space check.<br /> <br /> Switch the aggregation loops to a bounded append helper and<br /> reject enumeration packages whose combined strings do not fit<br /> in the destination buffers.<br /> <br /> [ij: add include]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: core: Fix integer overflow in UNMAP bounds check<br /> <br /> sbc_execute_unmap() checks LBA + range does not exceed the device capacity,<br /> but does not guard against LBA + range wrapping around on 64-bit overflow.<br /> <br /> Add an overflow check matching the pattern already used for WRITE_SAME in<br /> the same file.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: Fix potential race condition in TLB sync<br /> <br /> During the TLB sync, we need to traverse and modify the page table,<br /> so we should hold the page table lock. Since full SMP support for<br /> threads within the same process is still missing, let&amp;#39;s disable the<br /> split page table lock for simplicity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: raw: fix use-after-free on cdev close<br /> <br /> This addresses a use-after-free bug when a raw bundle is disconnected<br /> but its chardev is still opened by an application. When the application<br /> releases the cdev, it causes the following panic when init on free is<br /> enabled (CONFIG_INIT_ON_FREE_DEFAULT_ON=y):<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 0 PID: 139 at lib/refcount.c:28 refcount_warn_saturate+0xd0/0x130<br /> ...<br /> Call Trace:<br /> <br /> cdev_put+0x18/0x30<br /> __fput+0x255/0x2a0<br /> __x64_sys_close+0x3d/0x80<br /> do_syscall_64+0xa4/0x290<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The cdev is contained in the "gb_raw" structure, which is freed in the<br /> disconnect operation. When the cdev is released at a later time,<br /> cdev_put gets an address that points to freed memory.<br /> <br /> To fix this use-after-free, convert the struct device from a pointer to<br /> being embedded, that makes the lifetime of the cdev and of this device<br /> the same. Then, use cdev_device_add, which guarantees that the device<br /> won&amp;#39;t be released until all references to the cdev have been released.<br /> Finally, delegate the freeing of the structure to the device release<br /> function, instead of freeing immediately in the disconnect callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg<br /> <br /> In nfsd4_add_rdaccess_to_wrdeleg, if fp-&gt;fi_fds[O_RDONLY] is already<br /> set by another thread, __nfs4_file_get_access should not be called<br /> to increment the nfs4_file access count since that was already done<br /> by the thread that added READ access to the file. The extra fi_access<br /> count in nfs4_file can prevent the corresponding nfsd_file from being<br /> freed.<br /> <br /> When stopping nfs-server service, these extra access counts trigger a<br /> BUG in kmem_cache_destroy() that shows nfsd_file object remaining on<br /> __kmem_cache_shutdown.<br /> <br /> This problem can be reproduced by running the Git project&amp;#39;s test<br /> suite over NFS.