Vulnerabilities

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.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().<br /> <br /> As syzbot reported [0], mpls_route_input_rcu() can be called<br /> from mpls_getroute(), where is under RTNL.<br /> <br /> net-&gt;mpls.platform_label is only updated under RTNL.<br /> <br /> Let&amp;#39;s use rcu_dereference_rtnl() in mpls_route_input_rcu() to<br /> silence the splat.<br /> <br /> [0]:<br /> WARNING: suspicious RCU usage<br /> 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted<br /> ----------------------------<br /> net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by syz.2.4451/17730:<br /> #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]<br /> #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961<br /> <br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #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+0x16c/0x1f0 lib/dump_stack.c:120<br /> lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865<br /> mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84<br /> mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381<br /> rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964<br /> netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]<br /> netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339<br /> netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg net/socket.c:727 [inline]<br /> ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620<br /> __sys_sendmmsg+0x200/0x420 net/socket.c:2709<br /> __do_sys_sendmmsg net/socket.c:2736 [inline]<br /> __se_sys_sendmmsg net/socket.c:2733 [inline]<br /> __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f0a2818e969<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133<br /> RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969<br /> RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003<br /> RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add free_transport ops in ksmbd connection<br /> <br /> free_transport function for tcp connection can be called from smbdirect.<br /> It will cause kernel oops. This patch add free_transport ops in ksmbd<br /> connection, and add each free_transports for tcp and smbdirect.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aoe: clean device rq_list in aoedev_downdev()<br /> <br /> An aoe device&amp;#39;s rq_list contains accepted block requests that are<br /> waiting to be transmitted to the aoe target. This queue was added as<br /> part of the conversion to blk_mq. However, the queue was not cleaned out<br /> when an aoe device is downed which caused blk_mq_freeze_queue() to sleep<br /> indefinitely waiting for those requests to complete, causing a hang. This<br /> fix cleans out the queue before calling blk_mq_freeze_queue().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fgraph: Do not enable function_graph tracer when setting funcgraph-args<br /> <br /> When setting the funcgraph-args option when function graph tracer is net<br /> enabled, it incorrectly enables it. Worse, it unregisters itself when it<br /> was never registered. Then when it gets enabled again, it will register<br /> itself a second time causing a WARNing.<br /> <br /> ~# echo 1 &gt; /sys/kernel/tracing/options/funcgraph-args<br /> ~# head -20 /sys/kernel/tracing/trace<br /> # tracer: nop<br /> #<br /> # entries-in-buffer/entries-written: 813/26317372 #P:8<br /> #<br /> # _-----=&gt; irqs-off/BH-disabled<br /> # / _----=&gt; need-resched<br /> # | / _---=&gt; hardirq/softirq<br /> # || / _--=&gt; preempt-depth<br /> # ||| / _-=&gt; migrate-disable<br /> # |||| / delay<br /> # TASK-PID CPU# ||||| TIMESTAMP FUNCTION<br /> # | | | ||||| | |<br /> -0 [007] d..4. 358.966010: 7) 1.692 us | fetch_next_timer_interrupt(basej=4294981640, basem=357956000000, base_local=0xffff88823c3ae040, base_global=0xffff88823c3af300, tevt=0xffff888100e47cb8);<br /> -0 [007] d..4. 358.966012: 7) | tmigr_cpu_deactivate(nextexp=357988000000) {<br /> -0 [007] d..4. 358.966013: 7) | _raw_spin_lock(lock=0xffff88823c3b2320) {<br /> -0 [007] d..4. 358.966014: 7) 0.981 us | preempt_count_add(val=1);<br /> -0 [007] d..5. 358.966017: 7) 1.058 us | do_raw_spin_lock(lock=0xffff88823c3b2320);<br /> -0 [007] d..4. 358.966019: 7) 5.824 us | }<br /> -0 [007] d..5. 358.966021: 7) | tmigr_inactive_up(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) {<br /> -0 [007] d..5. 358.966022: 7) | tmigr_update_events(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) {<br /> <br /> Notice the "tracer: nop" at the top there. The current tracer is the "nop"<br /> tracer, but the content is obviously the function graph tracer.<br /> <br /> Enabling function graph tracing will cause it to register again and<br /> trigger a warning in the accounting:<br /> <br /> ~# echo function_graph &gt; /sys/kernel/tracing/current_tracer<br /> -bash: echo: write error: Device or resource busy<br /> <br /> With the dmesg of:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 7 PID: 1095 at kernel/trace/ftrace.c:3509 ftrace_startup_subops+0xc1e/0x1000<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 7 UID: 0 PID: 1095 Comm: bash Not tainted 6.16.0-rc2-test-00006-gea03de4105d3 #24 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:ftrace_startup_subops+0xc1e/0x1000<br /> Code: 48 b8 22 01 00 00 00 00 ad de 49 89 84 24 88 01 00 00 8b 44 24 08 89 04 24 e9 c3 f7 ff ff c7 04 24 ed ff ff ff e9 b7 f7 ff ff 0b c7 04 24 f0 ff ff ff e9 a9 f7 ff ff c7 04 24 f4 ff ff ff e9<br /> RSP: 0018:ffff888133cff948 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: 1ffff1102679ff31 RCX: 0000000000000000<br /> RDX: 1ffffffff0b27a60 RSI: ffffffff8593d2f0 RDI: ffffffff85941140<br /> RBP: 00000000000c2041 R08: ffffffffffffffff R09: ffffed1020240221<br /> R10: ffff88810120110f R11: ffffed1020240214 R12: ffffffff8593d2f0<br /> R13: ffffffff8593d300 R14: ffffffff85941140 R15: ffffffff85631100<br /> FS: 00007f7ec6f28740(0000) GS:ffff8882b5251000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7ec6f181c0 CR3: 000000012f1d0005 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __pfx_ftrace_startup_subops+0x10/0x10<br /> ? find_held_lock+0x2b/0x80<br /> ? ftrace_stub_direct_tramp+0x10/0x10<br /> ? ftrace_stub_direct_tramp+0x10/0x10<br /> ? trace_preempt_on+0xd0/0x110<br /> ? __pfx_trace_graph_entry_args+0x10/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()<br /> <br /> KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().<br /> <br /> Call Trace:<br /> [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8<br /> [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550<br /> [ 97.285732]<br /> [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11<br /> [ 97.287032] Hardware name: linux,dummy-virt (DT)<br /> [ 97.287815] Call trace:<br /> [ 97.288279] dump_backtrace+0xa0/0x128<br /> [ 97.288946] show_stack+0x20/0x38<br /> [ 97.289551] dump_stack_lvl+0x78/0xc8<br /> [ 97.290203] print_address_description.constprop.0+0x84/0x3c8<br /> [ 97.291159] print_report+0xb0/0x280<br /> [ 97.291792] kasan_report+0x84/0xd0<br /> [ 97.292421] __asan_load8+0x9c/0xc0<br /> [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8<br /> [ 97.293835] process_fetch_insn+0x770/0xa30<br /> [ 97.294562] kprobe_trace_func+0x254/0x3b0<br /> [ 97.295271] kprobe_dispatcher+0x98/0xe0<br /> [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210<br /> [ 97.296774] call_break_hook+0xc4/0x100<br /> [ 97.297451] brk_handler+0x24/0x78<br /> [ 97.298073] do_debug_exception+0xac/0x178<br /> [ 97.298785] el1_dbg+0x70/0x90<br /> [ 97.299344] el1h_64_sync_handler+0xcc/0xe8<br /> [ 97.300066] el1h_64_sync+0x78/0x80<br /> [ 97.300699] kernel_clone+0x0/0x500<br /> [ 97.301331] __arm64_sys_clone+0x70/0x90<br /> [ 97.302084] invoke_syscall+0x68/0x198<br /> [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150<br /> [ 97.303569] do_el0_svc+0x38/0x50<br /> [ 97.304164] el0_svc+0x44/0x1d8<br /> [ 97.304749] el0t_64_sync_handler+0x100/0x130<br /> [ 97.305500] el0t_64_sync+0x188/0x190<br /> [ 97.306151]<br /> [ 97.306475] The buggy address belongs to stack of task 1.sh/2550<br /> [ 97.307461] and is located at offset 0 in frame:<br /> [ 97.308257] __se_sys_clone+0x0/0x138<br /> [ 97.308910]<br /> [ 97.309241] This frame has 1 object:<br /> [ 97.309873] [48, 184) &amp;#39;args&amp;#39;<br /> [ 97.309876]<br /> [ 97.310749] The buggy address belongs to the virtual mapping at<br /> [ 97.310749] [ffff800089270000, ffff800089279000) created by:<br /> [ 97.310749] dup_task_struct+0xc0/0x2e8<br /> [ 97.313347]<br /> [ 97.313674] The buggy address belongs to the physical page:<br /> [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a<br /> [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff)<br /> [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000<br /> [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> [ 97.319445] page dumped because: kasan: bad access detected<br /> [ 97.320371]<br /> [ 97.320694] Memory state around the buggy address:<br /> [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 97.323846] &gt;ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00<br /> [ 97.325023] ^<br /> [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3<br /> [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> <br /> This issue seems to be related to the behavior of some gcc compilers and<br /> was also fixed on the s390 architecture before:<br /> <br /> commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")<br /> <br /> As described in that commit, regs_get_kernel_stack_nth() has confirmed that<br /> `addr` is on the stack, so reading the value at `*addr` should be allowed.<br /> Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.<br /> <br /> [will: Use &amp;#39;*addr&amp;#39; as the argument to READ_ONCE_NOCHECK()]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: get rid of the crit lock<br /> <br /> Get rid of the crit lock.<br /> That frees us from the error prone logic of try_locks.<br /> <br /> Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were<br /> protected by it already - replace crit lock by netdev lock when it was not<br /> the case.<br /> <br /> Lockdep reports that we should cancel the work under crit_lock [splat1],<br /> and that was the scheme we have mostly followed since [1] by Slawomir.<br /> But when that is done we still got into deadlocks [splat2]. So instead<br /> we should look at the bigger problem, namely "weird locking/scheduling"<br /> of the iavf. The first step to fix that is to remove the crit lock.<br /> I will followup with a -next series that simplifies scheduling/tasks.<br /> <br /> Cancel the work without netdev lock (weird unlock+lock scheme),<br /> to fix the [splat2] (which would be totally ugly if we would kept<br /> the crit lock).<br /> <br /> Extend protected part of iavf_watchdog_task() to include scheduling<br /> more work.<br /> <br /> Note that the removed comment in iavf_reset_task() was misplaced,<br /> it belonged to inside of the removed if condition, so it&amp;#39;s gone now.<br /> <br /> [splat1] - w/o this patch - The deadlock during VF removal:<br /> WARNING: possible circular locking dependency detected<br /> sh/3825 is trying to acquire lock:<br /> ((work_completion)(&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470<br /> but task is already holding lock:<br /> (&amp;adapter-&gt;crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]<br /> which lock already depends on the new lock.<br /> <br /> [splat2] - when cancelling work under crit lock, w/o this series,<br /> see [2] for the band aid attempt<br /> WARNING: possible circular locking dependency detected<br /> sh/3550 is trying to acquire lock:<br /> ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90<br /> but task is already holding lock:<br /> (&amp;dev-&gt;lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]<br /> which lock already depends on the new lock.<br /> <br /> [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation")<br /> [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()<br /> <br /> In fb_find_mode_cvt(), iff mode-&gt;refresh somehow happens to be 0x80000000,<br /> cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It&amp;#39;s<br /> then passed to fb_cvt_hperiod(), where it&amp;#39;s used as a divider -- division<br /> by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to<br /> avoid such overflow...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the Svace static<br /> analysis tool.