Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/deadline: only set free_cpus for online runqueues<br /> <br /> Commit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpus<br /> to reflect rd-&gt;online") introduced the cpudl_set/clear_freecpu<br /> functions to allow the cpu_dl::free_cpus mask to be manipulated<br /> by the deadline scheduler class rq_on/offline callbacks so the<br /> mask would also reflect this state.<br /> <br /> Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_mask<br /> from cpudl_find()") removed the check of the cpu_active_mask to<br /> save some processing on the premise that the cpudl::free_cpus<br /> mask already reflected the runqueue online state.<br /> <br /> Unfortunately, there are cases where it is possible for the<br /> cpudl_clear function to set the free_cpus bit for a CPU when the<br /> deadline runqueue is offline. When this occurs while a CPU is<br /> connected to the default root domain the flag may retain the bad<br /> state after the CPU has been unplugged. Later, a different CPU<br /> that is transitioning through the default root domain may push a<br /> deadline task to the powered down CPU when cpudl_find sees its<br /> free_cpus bit is set. If this happens the task will not have the<br /> opportunity to run.<br /> <br /> One example is outlined here:<br /> https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com<br /> <br /> Another occurs when the last deadline task is migrated from a<br /> CPU that has an offlined runqueue. The dequeue_task member of<br /> the deadline scheduler class will eventually call cpudl_clear<br /> and set the free_cpus bit for the CPU.<br /> <br /> This commit modifies the cpudl_clear function to be aware of the<br /> online state of the deadline runqueue so that the free_cpus mask<br /> can be updated appropriately.<br /> <br /> It is no longer necessary to manage the mask outside of the<br /> cpudl_set/clear functions so the cpudl_set/clear_freecpu<br /> functions are removed. In addition, since the free_cpus mask is<br /> now only updated under the cpudl lock the code was changed to<br /> use the non-atomic __cpumask functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Reset t_task_cdb pointer in error case<br /> <br /> If allocation of cmd-&gt;t_task_cdb fails, it remains NULL but is later<br /> dereferenced in the &amp;#39;err&amp;#39; path.<br /> <br /> In case of error, reset NULL t_task_cdb value to point at the default<br /> fixed-size buffer.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: frags: flush pending skbs in fqdir_pre_exit()<br /> <br /> We have been seeing occasional deadlocks on pernet_ops_rwsem since<br /> September in NIPA. The stuck task was usually modprobe (often loading<br /> a driver like ipvlan), trying to take the lock as a Writer.<br /> lockdep does not track readers for rwsems so the read wasn&amp;#39;t obvious<br /> from the reports.<br /> <br /> On closer inspection the Reader holding the lock was conntrack looping<br /> forever in nf_conntrack_cleanup_net_list(). Based on past experience<br /> with occasional NIPA crashes I looked thru the tests which run before<br /> the crash and noticed that the crash follows ip_defrag.sh. An immediate<br /> red flag. Scouring thru (de)fragmentation queues reveals skbs sitting<br /> around, holding conntrack references.<br /> <br /> The problem is that since conntrack depends on nf_defrag_ipv6,<br /> nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its<br /> netns exit hooks run _after_ conntrack&amp;#39;s netns exit hook.<br /> <br /> Flush all fragment queue SKBs during fqdir_pre_exit() to release<br /> conntrack references before conntrack cleanup runs. Also flush<br /> the queues in timer expiry handlers when they discover fqdir-&gt;dead<br /> is set, in case packet sneaks in while we&amp;#39;re running the pre_exit<br /> flush.<br /> <br /> The commit under Fixes is not exactly the culprit, but I think<br /> previously the timer firing would eventually unblock the spinning<br /> conntrack.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix XDP_TX path<br /> <br /> For XDP_TX action in bnxt_rx_xdp(), clearing of the event flags is not<br /> correct. __bnxt_poll_work() -&gt; bnxt_rx_pkt() -&gt; bnxt_rx_xdp() may be<br /> looping within NAPI and some event flags may be set in earlier<br /> iterations. In particular, if BNXT_TX_EVENT is set earlier indicating<br /> some XDP_TX packets are ready and pending, it will be cleared if it is<br /> XDP_TX action again. Normally, we will set BNXT_TX_EVENT again when we<br /> successfully call __bnxt_xmit_xdp(). But if the TX ring has no more<br /> room, the flag will not be set. This will cause the TX producer to be<br /> ahead but the driver will not hit the TX doorbell.<br /> <br /> For multi-buf XDP_TX, there is no need to clear the event flags and set<br /> BNXT_AGG_EVENT. The BNXT_AGG_EVENT flag should have been set earlier in<br /> bnxt_rx_pkt().<br /> <br /> The visible symptom of this is that the RX ring associated with the<br /> TX XDP ring will eventually become empty and all packets will be dropped.<br /> Because this condition will cause the driver to not refill the RX ring<br /> seeing that the TX ring has forever pending XDP_TX packets.<br /> <br /> The fix is to only clear BNXT_RX_EVENT when we have successfully<br /> called __bnxt_xmit_xdp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid updating compression context during writeback<br /> <br /> Bai, Shuangpeng reported a bug as below:<br /> <br /> Oops: divide error: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857<br /> Call Trace:<br /> <br /> f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline]<br /> __f2fs_write_data_pages fs/f2fs/data.c:3290 [inline]<br /> f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317<br /> do_writepages+0x38e/0x640 mm/page-writeback.c:2634<br /> filemap_fdatawrite_wbc mm/filemap.c:386 [inline]<br /> __filemap_fdatawrite_range mm/filemap.c:419 [inline]<br /> file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794<br /> f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294<br /> generic_write_sync include/linux/fs.h:3043 [inline]<br /> f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x7e9/0xe00 fs/read_write.c:686<br /> ksys_write+0x19d/0x2d0 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The bug was triggered w/ below race condition:<br /> <br /> fsync setattr ioctl<br /> - f2fs_do_sync_file<br /> - file_write_and_wait_range<br /> - f2fs_write_cache_pages<br /> : inode is non-compressed<br /> : cc.cluster_size =<br /> F2FS_I(inode)-&gt;i_cluster_size = 0<br /> - tag_pages_for_writeback<br /> - f2fs_setattr<br /> - truncate_setsize<br /> - f2fs_truncate<br /> - f2fs_fileattr_set<br /> - f2fs_setflags_common<br /> - set_compress_context<br /> : F2FS_I(inode)-&gt;i_cluster_size = 4<br /> : set_inode_flag(inode, FI_COMPRESSED_FILE)<br /> - f2fs_compressed_file<br /> : return true<br /> - f2fs_all_cluster_page_ready<br /> : "pgidx % cc-&gt;cluster_size" trigger dividing 0 issue<br /> <br /> Let&amp;#39;s change as below to fix this issue:<br /> - introduce a new atomic type variable .writeback in structure f2fs_inode_info<br /> to track the number of threads which calling f2fs_write_cache_pages().<br /> - use .i_sem lock to protect .writeback update.<br /> - check .writeback before update compression context in f2fs_setflags_common()<br /> to avoid race w/ -&gt;writepages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: Verify inode mode when loading from disk<br /> <br /> syzbot is reporting that S_IFMT bits of inode-&gt;i_mode can become bogus when<br /> the S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.<br /> <br /> According to [1], the permissions field was treated as reserved in Mac OS<br /> 8 and 9. According to [2], the reserved field was explicitly initialized<br /> with 0, and that field must remain 0 as long as reserved. Therefore, when<br /> the "mode" field is not 0 (i.e. no longer reserved), the file must be<br /> S_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/<br /> S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix return value of f2fs_recover_fsync_data()<br /> <br /> With below scripts, it will trigger panic in f2fs:<br /> <br /> mkfs.f2fs -f /dev/vdd<br /> mount /dev/vdd /mnt/f2fs<br /> touch /mnt/f2fs/foo<br /> sync<br /> echo 111 &gt;&gt; /mnt/f2fs/foo<br /> f2fs_io fsync /mnt/f2fs/foo<br /> f2fs_io shutdown 2 /mnt/f2fs<br /> umount /mnt/f2fs<br /> mount -o ro,norecovery /dev/vdd /mnt/f2fs<br /> or<br /> mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs<br /> <br /> F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0<br /> F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361f<br /> F2FS-fs (vdd): Stopped filesystem due to reason: 0<br /> F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1<br /> Filesystem f2fs get_tree() didn&amp;#39;t set fc-&gt;root, returned 1<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/super.c:1761!<br /> Oops: invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:vfs_get_tree.cold+0x18/0x1a<br /> Call Trace:<br /> <br /> fc_mount+0x13/0xa0<br /> path_mount+0x34e/0xc50<br /> __x64_sys_mount+0x121/0x150<br /> do_syscall_64+0x84/0x800<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fa6cc126cfe<br /> <br /> The root cause is we missed to handle error number returned from<br /> f2fs_recover_fsync_data() when mounting image w/ ro,norecovery or<br /> ro,disable_roll_forward mount option, result in returning a positive<br /> error number to vfs_get_tree(), fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix kernel BUG in ocfs2_find_victim_chain<br /> <br /> syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the<br /> `cl_next_free_rec` field of the allocation chain list (next free slot in<br /> the chain list) is 0, triggring the BUG_ON(!cl-&gt;cl_next_free_rec)<br /> condition in ocfs2_find_victim_chain() and panicking the kernel.<br /> <br /> To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),<br /> just before calling ocfs2_find_victim_chain(), the code block in it being<br /> executed when either of the following conditions is true:<br /> <br /> 1. `cl_next_free_rec` is equal to 0, indicating that there are no free<br /> chains in the allocation chain list<br /> 2. `cl_next_free_rec` is greater than `cl_count` (the total number of<br /> chains in the allocation chain list)<br /> <br /> Either of them being true is indicative of the fact that there are no<br /> chains left for usage.<br /> <br /> This is addressed using ocfs2_error(), which prints<br /> the error log for debugging purposes, rather than panicking the kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fsl-cpm: Check length parity before switching to 16 bit mode<br /> <br /> Commit fc96ec826bce ("spi: fsl-cpm: Use 16 bit mode for large transfers<br /> with even size") failed to make sure that the size is really even<br /> before switching to 16 bit mode. Until recently the problem went<br /> unnoticed because kernfs uses a pre-allocated bounce buffer of size<br /> PAGE_SIZE for reading EEPROM.<br /> <br /> But commit 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API")<br /> introduced an additional dynamically allocated bounce buffer whose size<br /> is exactly the size of the transfer, leading to a buffer overrun in<br /> the fsl-cpm driver when that size is odd.<br /> <br /> Add the missing length parity verification and remain in 8 bit mode<br /> when the length is not even.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create<br /> <br /> When sync() and link() are called concurrently, both threads may<br /> enter hfs_bnode_find() without finding the node in the hash table<br /> and proceed to create it.<br /> <br /> Thread A:<br /> hfsplus_write_inode()<br /> -&gt; hfsplus_write_system_inode()<br /> -&gt; hfs_btree_write()<br /> -&gt; hfs_bnode_find(tree, 0)<br /> -&gt; __hfs_bnode_create(tree, 0)<br /> <br /> Thread B:<br /> hfsplus_create_cat()<br /> -&gt; hfs_brec_insert()<br /> -&gt; hfs_bnode_split()<br /> -&gt; hfs_bmap_alloc()<br /> -&gt; hfs_bnode_find(tree, 0)<br /> -&gt; __hfs_bnode_create(tree, 0)<br /> <br /> In this case, thread A creates the bnode, sets refcnt=1, and hashes it.<br /> Thread B also tries to create the same bnode, notices it has already<br /> been inserted, drops its own instance, and uses the hashed one without<br /> getting the node.<br /> <br /> ```<br /> <br /> node2 = hfs_bnode_findhash(tree, cnid);<br /> if (!node2) { next_hash = tree-&gt;node_hash[hash];<br /> tree-&gt;node_hash[hash] = node;<br /> tree-&gt;node_hash_cnt++;<br /> } else { hash_lock);<br /> kfree(node);<br /> wait_event(node2-&gt;lock_wq,<br /> !test_bit(HFS_BNODE_NEW, &amp;node2-&gt;flags));<br /> return node2;<br /> }<br /> ```<br /> <br /> However, hfs_bnode_find() requires each call to take a reference.<br /> Here both threads end up setting refcnt=1. When they later put the node,<br /> this triggers:<br /> <br /> BUG_ON(!atomic_read(&amp;node-&gt;refcnt))<br /> <br /> In this scenario, Thread B in fact finds the node in the hash table<br /> rather than creating a new one, and thus must take a reference.<br /> <br /> Fix this by calling hfs_bnode_get() when reusing a bnode newly created by<br /> another thread to ensure the refcount is updated correctly.<br /> <br /> A similar bug was fixed in HFS long ago in commit<br /> a9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create")<br /> but the same issue remained in HFS+ until now.

A flaw was found in Eclipse Che che-machine-exec. This vulnerability allows unauthenticated remote arbitrary command execution and secret exfiltration (SSH keys, tokens, etc.) from other users&amp;#39; Developer Workspace containers, via an unauthenticated JSON-RPC / websocket API exposed on TCP port 3333.

An issue in Semantic machines v5.4.8 allows attackers to bypass authentication via sending a crafted HTTP request to various API endpoints.