Vulnerabilities

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 /> 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 /> 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 /> jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()<br /> <br /> Since handle-&gt;h_transaction may be a NULL pointer, so we should change it<br /> to call is_handle_aborted(handle) first before dereferencing it.<br /> <br /> And the following data-race was reported in my fuzzer:<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata<br /> <br /> write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1:<br /> jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556<br /> __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358<br /> ext4_do_update_inode fs/ext4/inode.c:5220 [inline]<br /> ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869<br /> __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074<br /> ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103<br /> ....<br /> <br /> read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0:<br /> jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512<br /> __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358<br /> ext4_do_update_inode fs/ext4/inode.c:5220 [inline]<br /> ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869<br /> __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074<br /> ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103<br /> ....<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001<br /> ==================================================================<br /> <br /> This issue is caused by missing data-race annotation for jh-&gt;b_modified.<br /> Therefore, the missing annotation needs to be added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330<br /> <br /> The controller has a hardware bug that can hard hang the system when<br /> doing ATAPI DMAs without any trace of what happened. Depending on the<br /> device attached, it can also prevent the system from booting.<br /> <br /> In this case, the system hangs when reading the ATIP from optical media<br /> with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an<br /> Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,<br /> running at UDMA/33.<br /> <br /> The issue can be reproduced by running the same command with a cygwin<br /> build of cdrecord on WinXP, although it requires more attempts to cause<br /> it. The hang in that case is also resolved by forcing PIO. It doesn&amp;#39;t<br /> appear that VIA has produced any drivers for that OS, thus no known<br /> workaround exists.<br /> <br /> HDDs attached to the controller do not suffer from any DMA issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT<br /> <br /> When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in<br /> hard irq context, but the input_event() takes a spin_lock, which isn&amp;#39;t<br /> allowed there as it is converted to a rt_spin_lock().<br /> <br /> [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0<br /> ...<br /> [ 4054.290195] __might_resched+0x13c/0x1f4<br /> [ 4054.290209] rt_spin_lock+0x54/0x11c<br /> [ 4054.290219] input_event+0x48/0x80<br /> [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78<br /> [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438<br /> [ 4054.290257] hrtimer_interrupt+0xe4/0x240<br /> [ 4054.290269] arch_timer_handler_phys+0x2c/0x44<br /> [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c<br /> [ 4054.290297] handle_irq_desc+0x40/0x58<br /> [ 4054.290307] generic_handle_domain_irq+0x1c/0x28<br /> [ 4054.290316] gic_handle_irq+0x44/0xcc<br /> <br /> Considering the gpio_keys_irq_isr() can run in any context, e.g. it can<br /> be threaded, it seems there&amp;#39;s no point in requesting the timer isr to<br /> run in hard irq context.<br /> <br /> Relax the hrtimer not to use the hard context.

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 /> 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 /> 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 /> 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.