Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()<br /> <br /> Sometimes, when a file was read while it was being truncated by<br /> another NFS client, the kernel could deadlock because folio_unlock()<br /> was called twice, and the second call would XOR back the `PG_locked`<br /> flag.<br /> <br /> Most of the time (depending on the timing of the truncation), nobody<br /> notices the problem because folio_unlock() gets called three times,<br /> which flips `PG_locked` back off:<br /> <br /> 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,<br /> nfs_return_empty_folio<br /> 2. vfs_read, nfs_read_folio, ... netfs_read_collection,<br /> netfs_unlock_abandoned_read_pages<br /> 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,<br /> nfs_return_empty_folio<br /> <br /> The problem is that nfs_read_add_folio() is not supposed to unlock the<br /> folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is<br /> missing in nfs_return_empty_folio().<br /> <br /> Rarely this leads to a warning in netfs_read_collection():<br /> <br /> ------------[ cut here ]------------<br /> R=0000031c: folio 10 is not locked<br /> WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00<br /> [...]<br /> Workqueue: events_unbound netfs_read_collection_worker<br /> RIP: 0010:netfs_read_collection+0x7c0/0xf00<br /> [...]<br /> Call Trace:<br /> <br /> netfs_read_collection_worker+0x67/0x80<br /> process_one_work+0x12e/0x2c0<br /> worker_thread+0x295/0x3a0<br /> <br /> Most of the time, however, processes just get stuck forever in<br /> folio_wait_bit_common(), waiting for `PG_locked` to disappear, which<br /> never happens because nobody is really holding the folio lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/bpf: fix JIT code size calculation of bpf trampoline<br /> <br /> arch_bpf_trampoline_size() provides JIT size of the BPF trampoline<br /> before the buffer for JIT&amp;#39;ing it is allocated. The total number of<br /> instructions emitted for BPF trampoline JIT code depends on where<br /> the final image is located. So, the size arrived at with the dummy<br /> pass in arch_bpf_trampoline_size() can vary from the actual size<br /> needed in arch_prepare_bpf_trampoline(). When the instructions<br /> accounted in arch_bpf_trampoline_size() is less than the number of<br /> instructions emitted during the actual JIT compile of the trampoline,<br /> the below warning is produced:<br /> <br /> WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc<br /> <br /> which is:<br /> <br /> /* Make sure the trampoline generation logic doesn&amp;#39;t overflow */<br /> if (image &amp;&amp; WARN_ON_ONCE(&amp;image[ctx-&gt;idx] &gt;<br /> (u32 *)rw_image_end - BPF_INSN_SAFETY)) {<br /> <br /> So, during the dummy pass, instead of providing some arbitrary image<br /> location, account for maximum possible instructions if and when there<br /> is a dependency with image location for JIT&amp;#39;ing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Fix OOB memory read access in KUnit test<br /> <br /> KASAN reported out of bounds access - cs_dsp_mock_bin_add_name_or_info(),<br /> because the source string length was rounded up to the allocation size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: fbnic: avoid double free when failing to DMA-map FW msg<br /> <br /> The semantics are that caller of fbnic_mbx_map_msg() retains<br /> the ownership of the message on error. All existing callers<br /> dutifully free the page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: check jffs2_prealloc_raw_node_refs() result in few other places<br /> <br /> Fuzzing hit another invalid pointer dereference due to the lack of<br /> checking whether jffs2_prealloc_raw_node_refs() completed successfully.<br /> Subsequent logic implies that the node refs have been allocated.<br /> <br /> Handle that. The code is ready for propagating the error upwards.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600<br /> Call Trace:<br /> jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline]<br /> jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118<br /> jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253<br /> jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167<br /> jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362<br /> jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302<br /> generic_perform_write+0x2c2/0x500 mm/filemap.c:3347<br /> __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465<br /> generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497<br /> call_write_iter include/linux/fs.h:2039 [inline]<br /> do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740<br /> do_iter_write+0x18c/0x710 fs/read_write.c:866<br /> vfs_writev+0x1db/0x6a0 fs/read_write.c:939<br /> do_pwritev fs/read_write.c:1036 [inline]<br /> __do_sys_pwritev fs/read_write.c:1083 [inline]<br /> __se_sys_pwritev fs/read_write.c:1078 [inline]<br /> __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078<br /> do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Fix OOB memory read access in KUnit test (wmfw info)<br /> <br /> KASAN reported out of bounds access - cs_dsp_mock_wmfw_add_info(),<br /> because the source string length was rounded up to the allocation size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Fix OOB memory read access in KUnit test (ctl cache)<br /> <br /> KASAN reported out of bounds access - cs_dsp_ctl_cache_init_multiple_offsets().<br /> The code uses mock_coeff_template.length_bytes (4 bytes) for register value<br /> allocations. But later, this length is set to 8 bytes which causes<br /> test code failures.<br /> <br /> As fix, just remove the lenght override, keeping the original value 4<br /> for all operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: cortina: Use TOE/TSO on all TCP<br /> <br /> It is desireable to push the hardware accelerator to also<br /> process non-segmented TCP frames: we pass the skb-&gt;len<br /> to the "TOE/TSO" offloader and it will handle them.<br /> <br /> Without this quirk the driver becomes unstable and lock<br /> up and and crash.<br /> <br /> I do not know exactly why, but it is probably due to the<br /> TOE (TCP offload engine) feature that is coupled with the<br /> segmentation feature - it is not possible to turn one<br /> part off and not the other, either both TOE and TSO are<br /> active, or neither of them.<br /> <br /> Not having the TOE part active seems detrimental, as if<br /> that hardware feature is not really supposed to be turned<br /> off.<br /> <br /> The datasheet says:<br /> <br /> "Based on packet parsing and TCP connection/NAT table<br /> lookup results, the NetEngine puts the packets<br /> belonging to the same TCP connection to the same queue<br /> for the software to process. The NetEngine puts<br /> incoming packets to the buffer or series of buffers<br /> for a jumbo packet. With this hardware acceleration,<br /> IP/TCP header parsing, checksum validation and<br /> connection lookup are offloaded from the software<br /> processing."<br /> <br /> After numerous tests with the hardware locking up after<br /> something between minutes and hours depending on load<br /> using iperf3 I have concluded this is necessary to stabilize<br /> the hardware.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Use memcpy() for BIOS version<br /> <br /> The strlcat() with FORTIFY support is triggering a panic because it<br /> thinks the target buffer will overflow although the correct target<br /> buffer size is passed in.<br /> <br /> Anyway, instead of memset() with 0 followed by a strlcat(), just use<br /> memcpy() and ensure that the resulting buffer is NULL terminated.<br /> <br /> BIOSVersion is only used for the lpfc_printf_log() which expects a<br /> properly terminated string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to bail out in get_new_segment()<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc<br /> pc : new_curseg+0x5e8/0x6dc<br /> Call trace:<br /> new_curseg+0x5e8/0x6dc<br /> f2fs_allocate_data_block+0xa54/0xe28<br /> do_write_page+0x6c/0x194<br /> f2fs_do_write_node_page+0x38/0x78<br /> __write_node_page+0x248/0x6d4<br /> f2fs_sync_node_pages+0x524/0x72c<br /> f2fs_write_checkpoint+0x4bc/0x9b0<br /> __checkpoint_and_complete_reqs+0x80/0x244<br /> issue_checkpoint_thread+0x8c/0xec<br /> kthread+0x114/0x1bc<br /> ret_from_fork+0x10/0x20<br /> <br /> get_new_segment() detects inconsistent status in between free_segmap<br /> and free_secmap, let&amp;#39;s record such error into super block, and bail<br /> out get_new_segment() instead of continue using the segment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/sgx: Prevent attempts to reclaim poisoned pages<br /> <br /> TL;DR: SGX page reclaim touches the page to copy its contents to<br /> secondary storage. SGX instructions do not gracefully handle machine<br /> checks. Despite this, the existing SGX code will try to reclaim pages<br /> that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.<br /> <br /> The longer story:<br /> <br /> Pages used by an enclave only get epc_page-&gt;poison set in<br /> arch_memory_failure() but they currently stay on sgx_active_page_list until<br /> sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.<br /> <br /> epc_page-&gt;poison is not checked in the reclaimer logic meaning that, if other<br /> conditions are met, an attempt will be made to reclaim an EPC page that was<br /> poisoned. This is bad because 1. we don&amp;#39;t want that page to end up added<br /> to another enclave and 2. it is likely to cause one core to shut down<br /> and the kernel to panic.<br /> <br /> Specifically, reclaiming uses microcode operations including "EWB" which<br /> accesses the EPC page contents to encrypt and write them out to non-SGX<br /> memory. Those operations cannot handle MCEs in their accesses other than<br /> by putting the executing core into a special shutdown state (affecting<br /> both threads with HT.) The kernel will subsequently panic on the<br /> remaining cores seeing the core didn&amp;#39;t enter MCE handler(s) in time.<br /> <br /> Call sgx_unmark_page_reclaimable() to remove the affected EPC page from<br /> sgx_active_page_list on memory error to stop it being considered for<br /> reclaiming.<br /> <br /> Testing epc_page-&gt;poison in sgx_reclaim_pages() would also work but I assume<br /> it&amp;#39;s better to add code in the less likely paths.<br /> <br /> The affected EPC page is not added to &amp;node-&gt;sgx_poison_page_list until<br /> later in sgx_encl_release()-&gt;sgx_free_epc_page() when it is EREMOVEd.<br /> Membership on other lists doesn&amp;#39;t change to avoid changing any of the<br /> lists&amp;#39; semantics except for sgx_active_page_list. There&amp;#39;s a "TBD" comment<br /> in arch_memory_failure() about pre-emptive actions, the goal here is not<br /> to address everything that it may imply.<br /> <br /> This also doesn&amp;#39;t completely close the time window when a memory error<br /> notification will be fatal (for a not previously poisoned EPC page) --<br /> the MCE can happen after sgx_reclaim_pages() has selected its candidates<br /> or even *inside* a microcode operation (actually easy to trigger due to<br /> the amount of time spent in them.)<br /> <br /> The spinlock in sgx_unmark_page_reclaimable() is safe because<br /> memory_failure() runs in process context and no spinlocks are held,<br /> explicitly noted in a mm/memory-failure.c comment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: Log an error when close_all_cached_dirs fails<br /> <br /> Under low-memory conditions, close_all_cached_dirs() can&amp;#39;t move the<br /> dentries to a separate list to dput() them once the locks are dropped.<br /> This will result in a "Dentry still in use" error, so add an error<br /> message that makes it clear this is what happened:<br /> <br /> [ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries<br /> [ 495.281595] ------------[ cut here ]------------<br /> [ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs]<br /> [ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0<br /> <br /> Also, bail out of looping through all tcons as soon as a single<br /> allocation fails, since we&amp;#39;re already in trouble, and kmalloc() attempts<br /> for subseqeuent tcons are likely to fail just like the first one did.