Vulnerabilities

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.

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 /> perf/x86/intel: Fix crash in icl_update_topdown_event()<br /> <br /> The perf_fuzzer found a hard-lockup crash on a RaptorLake machine:<br /> <br /> Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000<br /> CPU: 23 UID: 0 PID: 0 Comm: swapper/23<br /> Tainted: [W]=WARN<br /> Hardware name: Dell Inc. Precision 9660/0VJ762<br /> RIP: 0010:native_read_pmc+0x7/0x40<br /> Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ...<br /> RSP: 000:fffb03100273de8 EFLAGS: 00010046<br /> ....<br /> Call Trace:<br /> <br /> icl_update_topdown_event+0x165/0x190<br /> ? ktime_get+0x38/0xd0<br /> intel_pmu_read_event+0xf9/0x210<br /> __perf_event_read+0xf9/0x210<br /> <br /> CPUs 16-23 are E-core CPUs that don&amp;#39;t support the perf metrics feature.<br /> The icl_update_topdown_event() should not be invoked on these CPUs.<br /> <br /> It&amp;#39;s a regression of commit:<br /> <br /> f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc-&gt;enabled in sample read")<br /> <br /> The bug introduced by that commit is that the is_topdown_event() function<br /> is mistakenly used to replace the is_topdown_count() call to check if the<br /> topdown functions for the perf metrics feature should be invoked.<br /> <br /> Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: atm: add lec_mutex<br /> <br /> syzbot found its way in net/atm/lec.c, and found an error path<br /> in lecd_attach() could leave a dangling pointer in dev_lec[].<br /> <br /> Add a mutex to protect dev_lecp[] uses from lecd_attach(),<br /> lec_vcc_attach() and lec_mcast_attach().<br /> <br /> Following patch will use this mutex for /proc/net/atm/lec.<br /> <br /> BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline]<br /> BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008<br /> Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142<br /> <br /> CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xcd/0x680 mm/kasan/report.c:521<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:634<br /> lecd_attach net/atm/lec.c:751 [inline]<br /> lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008<br /> do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159<br /> sock_do_ioctl+0x118/0x280 net/socket.c:1190<br /> sock_ioctl+0x227/0x6b0 net/socket.c:1311<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Allocated by task 6132:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __do_kmalloc_node mm/slub.c:4328 [inline]<br /> __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015<br /> alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711<br /> lecd_attach net/atm/lec.c:737 [inline]<br /> lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008<br /> do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159<br /> sock_do_ioctl+0x118/0x280 net/socket.c:1190<br /> sock_ioctl+0x227/0x6b0 net/socket.c:1311<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 6132:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576<br /> poison_slab_object mm/kasan/common.c:247 [inline]<br /> __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264<br /> kasan_slab_free include/linux/kasan.h:233 [inline]<br /> slab_free_hook mm/slub.c:2381 [inline]<br /> slab_free mm/slub.c:4643 [inline]<br /> kfree+0x2b4/0x4d0 mm/slub.c:4842<br /> free_netdev+0x6c5/0x910 net/core/dev.c:11892<br /> lecd_attach net/atm/lec.c:744 [inline]<br /> lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008<br /> do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159<br /> sock_do_ioctl+0x118/0x280 net/socket.c:1190<br /> sock_ioctl+0x227/0x6b0 net/socket.c:1311<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893