Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Fix race in push_rt_task<br /> <br /> Overview<br /> ========<br /> When a CPU chooses to call push_rt_task and picks a task to push to<br /> another CPU&amp;#39;s runqueue then it will call find_lock_lowest_rq method<br /> which would take a double lock on both CPUs&amp;#39; runqueues. If one of the<br /> locks aren&amp;#39;t readily available, it may lead to dropping the current<br /> runqueue lock and reacquiring both the locks at once. During this window<br /> it is possible that the task is already migrated and is running on some<br /> other CPU. These cases are already handled. However, if the task is<br /> migrated and has already been executed and another CPU is now trying to<br /> wake it up (ttwu) such that it is queued again on the runqeue<br /> (on_rq is 1) and also if the task was run by the same CPU, then the<br /> current checks will pass even though the task was migrated out and is no<br /> longer in the pushable tasks list.<br /> <br /> Crashes<br /> =======<br /> This bug resulted in quite a few flavors of crashes triggering kernel<br /> panics with various crash signatures such as assert failures, page<br /> faults, null pointer dereferences, and queue corruption errors all<br /> coming from scheduler itself.<br /> <br /> Some of the crashes:<br /> -&gt; kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx &gt;= MAX_RT_PRIO)<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? die+0x2a/0x50<br /> ? do_trap+0x85/0x100<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? do_error_trap+0x64/0xa0<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? exc_invalid_op+0x4c/0x60<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? pick_next_task_rt+0x6e/0x1d0<br /> __schedule+0x5cb/0x790<br /> ? update_ts_time_stats+0x55/0x70<br /> schedule_idle+0x1e/0x40<br /> do_idle+0x15e/0x200<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x117/0x160<br /> secondary_startup_64_no_verify+0xb0/0xbb<br /> <br /> -&gt; BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? no_context+0x183/0x350<br /> ? __warn+0x8a/0xe0<br /> ? exc_page_fault+0x3d6/0x520<br /> ? asm_exc_page_fault+0x1e/0x30<br /> ? pick_next_task_rt+0xb5/0x1d0<br /> ? pick_next_task_rt+0x8c/0x1d0<br /> __schedule+0x583/0x7e0<br /> ? update_ts_time_stats+0x55/0x70<br /> schedule_idle+0x1e/0x40<br /> do_idle+0x15e/0x200<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x117/0x160<br /> secondary_startup_64_no_verify+0xb0/0xbb<br /> <br /> -&gt; BUG: unable to handle page fault for address: ffff9464daea5900<br /> kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq-&gt;cpu != task_cpu(p))<br /> <br /> -&gt; kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq-&gt;nr_running)<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? die+0x2a/0x50<br /> ? do_trap+0x85/0x100<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? do_error_trap+0x64/0xa0<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? exc_invalid_op+0x4c/0x60<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? dequeue_top_rt_rq+0xa2/0xb0<br /> dequeue_rt_entity+0x1f/0x70<br /> dequeue_task_rt+0x2d/0x70<br /> __schedule+0x1a8/0x7e0<br /> ? blk_finish_plug+0x25/0x40<br /> schedule+0x3c/0xb0<br /> futex_wait_queue_me+0xb6/0x120<br /> futex_wait+0xd9/0x240<br /> do_futex+0x344/0xa90<br /> ? get_mm_exe_file+0x30/0x60<br /> ? audit_exe_compare+0x58/0x70<br /> ? audit_filter_rules.constprop.26+0x65e/0x1220<br /> __x64_sys_futex+0x148/0x1f0<br /> do_syscall_64+0x30/0x80<br /> entry_SYSCALL_64_after_hwframe+0x62/0xc7<br /> <br /> -&gt; BUG: unable to handle page fault for address: ffff8cf3608bc2c0<br /> Call Trace:<br /> ? __die_body+0x1a/0x60<br /> ? no_context+0x183/0x350<br /> ? spurious_kernel_fault+0x171/0x1c0<br /> ? exc_page_fault+0x3b6/0x520<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? asm_exc_page_fault+0x1e/0x30<br /> ? _cond_resched+0x15/0x30<br /> ? futex_wait_queue_me+0xc8/0x120<br /> ? futex_wait+0xd9/0x240<br /> ? try_to_wake_up+0x1b8/0x490<br /> ? futex_wake+0x78/0x160<br /> ? do_futex+0xcd/0xa90<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? plist_del+0x6a/0xd0<br /> ? plist_check_list+0x15/0x40<br /> ? plist_check_list+0x2e/0x40<br /> ? dequeue_pushable_task+0x20/0x70<br /> ? __schedule+0x382/0x7e0<br /> ? asm_sysvec_reschedule_i<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc64/ftrace: fix clobbered r15 during livepatching<br /> <br /> While r15 is clobbered always with PPC_FTRACE_OUT_OF_LINE, it is<br /> not restored in livepatch sequence leading to not so obvious fails<br /> like below:<br /> <br /> BUG: Unable to handle kernel data access on write at 0xc0000000000f9078<br /> Faulting instruction address: 0xc0000000018ff958<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP: c0000000018ff958 LR: c0000000018ff930 CTR: c0000000009c0790<br /> REGS: c00000005f2e7790 TRAP: 0300 Tainted: G K (6.14.0+)<br /> MSR: 8000000000009033 CR: 2822880b XER: 20040000<br /> CFAR: c0000000008addc0 DAR: c0000000000f9078 DSISR: 0a000000 IRQMASK: 1<br /> GPR00: c0000000018f2584 c00000005f2e7a30 c00000000280a900 c000000017ffa488<br /> GPR04: 0000000000000008 0000000000000000 c0000000018f24fc 000000000000000d<br /> GPR08: fffffffffffe0000 000000000000000d 0000000000000000 0000000000008000<br /> GPR12: c0000000009c0790 c000000017ffa480 c00000005f2e7c78 c0000000000f9070<br /> GPR16: c00000005f2e7c90 0000000000000000 0000000000000000 0000000000000000<br /> GPR20: 0000000000000000 c00000005f3efa80 c00000005f2e7c60 c00000005f2e7c88<br /> GPR24: c00000005f2e7c60 0000000000000001 c0000000000f9078 0000000000000000<br /> GPR28: 00007fff97960000 c000000017ffa480 0000000000000000 c0000000000f9078<br /> ...<br /> Call Trace:<br /> check_heap_object+0x34/0x390 (unreliable)<br /> __mutex_unlock_slowpath.isra.0+0xe4/0x230<br /> seq_read_iter+0x430/0xa90<br /> proc_reg_read_iter+0xa4/0x200<br /> vfs_read+0x41c/0x510<br /> ksys_read+0xa4/0x190<br /> system_call_exception+0x1d0/0x440<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Fix it by restoring r15 always.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imagination: fix a potential memory leak in e5010_probe()<br /> <br /> Add video_device_release() to release the memory allocated by<br /> video_device_alloc() if something goes wrong.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: Initialize ssc before laundromat_work to prevent NULL dereference<br /> <br /> In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through<br /> nfs4_laundromat -&gt; nfsd4_ssc_expire_umount. If nfsd_ssc isn&amp;#39;t initialized,<br /> this can cause NULL pointer dereference.<br /> <br /> Normally the delayed start of laundromat_work allows sufficient time for<br /> nfsd_ssc initialization to complete. However, when the kernel waits too<br /> long for userspace responses (e.g. in nfs4_state_start_net -&gt;<br /> nfsd4_end_grace -&gt; nfsd4_record_grace_done -&gt; nfsd4_cld_grace_done -&gt;<br /> cld_pipe_upcall -&gt; __cld_pipe_upcall -&gt; wait_for_completion path), the<br /> delayed work may start before nfsd_ssc initialization finishes.<br /> <br /> Fix this by moving nfsd_ssc initialization before starting laundromat_work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: validate AG parameters in dbMount() to prevent crashes<br /> <br /> Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch<br /> corrupted metadata early and avoid undefined behavior in dbAllocAG.<br /> Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:<br /> <br /> - agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift<br /> (L2LPERCTL - 2*agheight) &gt;= 0.<br /> - agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight))<br /> ensures agperlev &gt;= 1.<br /> - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5).<br /> - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG;<br /> 2^(10 - 2*agheight) prevents division to 0.<br /> - agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within<br /> stree (size 1365).<br /> - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).<br /> <br /> UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9<br /> shift exponent -335544310 is negative<br /> CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> ubsan_epilogue lib/ubsan.c:231 [inline]<br /> __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468<br /> dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400<br /> dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613<br /> jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105<br /> jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cxusb: no longer judge rbuf when the write fails<br /> <br /> syzbot reported a uninit-value in cxusb_i2c_xfer. [1]<br /> <br /> Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()<br /> succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()<br /> will be executed to read rlen bytes of data from the dvb device into the<br /> rbuf.<br /> <br /> In this case, although rlen is 1, the write operation failed which resulted<br /> in the dvb read operation not being executed, and ultimately variable i was<br /> not initialized.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]<br /> BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196<br /> cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]<br /> cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196<br /> __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1<br /> i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315<br /> i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343<br /> i2c_master_send include/linux/i2c.h:109 [inline]<br /> i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183<br /> do_loop_readv_writev fs/read_write.c:848 [inline]<br /> vfs_writev+0x963/0x14e0 fs/read_write.c:1057<br /> do_writev+0x247/0x5c0 fs/read_write.c:1101<br /> __do_sys_writev fs/read_write.c:1169 [inline]<br /> __se_sys_writev fs/read_write.c:1166 [inline]<br /> __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166<br /> x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: Terminating the subsequent process of initialization failure<br /> <br /> syzbot reported a slab-use-after-free Read in vidtv_mux_init. [1]<br /> <br /> After PSI initialization fails, the si member is accessed again, resulting<br /> in this uaf.<br /> <br /> After si initialization fails, the subsequent process needs to be exited.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline]<br /> BUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524<br /> Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059<br /> <br /> CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0<br /> Hardware name: Google Compute Engine, BIOS Google 02/12/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+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:634<br /> vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78<br /> vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524<br /> vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194<br /> vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239<br /> dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973<br /> dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]<br /> dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537<br /> dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564<br /> dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]<br /> dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246<br /> __fput+0x3ff/0xb70 fs/file_table.c:464<br /> task_work_run+0x14e/0x250 kernel/task_work.c:227<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0xad8/0x2d70 kernel/exit.c:938<br /> do_group_exit+0xd3/0x2a0 kernel/exit.c:1087<br /> __do_sys_exit_group kernel/exit.c:1098 [inline]<br /> __se_sys_exit_group kernel/exit.c:1096 [inline]<br /> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096<br /> x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f871d58d169<br /> Code: Unable to access opcode bytes at 0x7f871d58d13f.<br /> RSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169<br /> RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0<br /> R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003<br /> R13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840<br /> <br /> <br /> Allocated by task 6059:<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 /> kmalloc_noprof include/linux/slab.h:901 [inline]<br /> kzalloc_noprof include/linux/slab.h:1037 [inline]<br /> vidtv_psi_pat_table_init drivers/media/test-drivers/vidtv/vidtv_psi.c:970<br /> vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:423<br /> vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519<br /> vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194<br /> vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239<br /> dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973<br /> dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]<br /> dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537<br /> dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564<br /> dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]<br /> dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246<br /> __fput+0x3ff/0xb70 fs/file_tabl<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix race between nfsd registration and exports_proc<br /> <br /> As of now nfsd calls create_proc_exports_entry() at start of init_nfsd<br /> and cleanup by remove_proc_entry() at last of exit_nfsd.<br /> <br /> Which causes kernel OOPs if there is race between below 2 operations:<br /> (i) exportfs -r<br /> (ii) mount -t nfsd none /proc/fs/nfsd<br /> <br /> for 5.4 kernel ARM64:<br /> <br /> CPU 1:<br /> el1_irq+0xbc/0x180<br /> arch_counter_get_cntvct+0x14/0x18<br /> running_clock+0xc/0x18<br /> preempt_count_add+0x88/0x110<br /> prep_new_page+0xb0/0x220<br /> get_page_from_freelist+0x2d8/0x1778<br /> __alloc_pages_nodemask+0x15c/0xef0<br /> __vmalloc_node_range+0x28c/0x478<br /> __vmalloc_node_flags_caller+0x8c/0xb0<br /> kvmalloc_node+0x88/0xe0<br /> nfsd_init_net+0x6c/0x108 [nfsd]<br /> ops_init+0x44/0x170<br /> register_pernet_operations+0x114/0x270<br /> register_pernet_subsys+0x34/0x50<br /> init_nfsd+0xa8/0x718 [nfsd]<br /> do_one_initcall+0x54/0x2e0<br /> <br /> CPU 2 :<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> <br /> PC is at : exports_net_open+0x50/0x68 [nfsd]<br /> <br /> Call trace:<br /> exports_net_open+0x50/0x68 [nfsd]<br /> exports_proc_open+0x2c/0x38 [nfsd]<br /> proc_reg_open+0xb8/0x198<br /> do_dentry_open+0x1c4/0x418<br /> vfs_open+0x38/0x48<br /> path_openat+0x28c/0xf18<br /> do_filp_open+0x70/0xe8<br /> do_sys_open+0x154/0x248<br /> <br /> Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().<br /> <br /> and same is happening on latest 6.14 kernel as well:<br /> <br /> [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty<br /> ...<br /> [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48<br /> ...<br /> [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4<br /> ...<br /> [ 285.469695] Call trace:<br /> [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)<br /> [ 285.470488] seq_read+0xe0/0x11c<br /> [ 285.470675] proc_reg_read+0x9c/0xf0<br /> [ 285.470874] vfs_read+0xc4/0x2fc<br /> [ 285.471057] ksys_read+0x6c/0xf4<br /> [ 285.471231] __arm64_sys_read+0x1c/0x28<br /> [ 285.471428] invoke_syscall+0x44/0x100<br /> [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0<br /> [ 285.471870] do_el0_svc_compat+0x1c/0x34<br /> [ 285.472073] el0_svc_compat+0x2c/0x80<br /> [ 285.472265] el0t_32_sync_handler+0x90/0x140<br /> [ 285.472473] el0t_32_sync+0x19c/0x1a0<br /> [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)<br /> [ 285.473422] ---[ end trace 0000000000000000 ]---<br /> <br /> It reproduced simply with below script:<br /> while [ 1 ]<br /> do<br /> /exportfs -r<br /> done &amp;<br /> <br /> while [ 1 ]<br /> do<br /> insmod /nfsd.ko<br /> mount -t nfsd none /proc/fs/nfsd<br /> umount /proc/fs/nfsd<br /> rmmod nfsd<br /> done &amp;<br /> <br /> So exporting interfaces to user space shall be done at last and<br /> cleanup at first place.<br /> <br /> With change there is no Kernel OOPs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: kvaser_pciefd: refine error prone echo_skb_max handling logic<br /> <br /> echo_skb_max should define the supported upper limit of echo_skb[]<br /> allocated inside the netdevice&amp;#39;s priv. The corresponding size value<br /> provided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNT<br /> which is 17.<br /> <br /> But later echo_skb_max is rounded up to the nearest power of two (for the<br /> max case, that would be 32) and the tx/ack indices calculated further<br /> during tx/rx may exceed the upper array boundary. Kasan reported this for<br /> the ack case inside kvaser_pciefd_handle_ack_packet(), though the xmit<br /> function has actually caught the same thing earlier.<br /> <br /> BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528<br /> Read of size 8 at addr ffff888105e4f078 by task swapper/4/0<br /> <br /> CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary)<br /> Call Trace:<br /> <br /> dump_stack_lvl lib/dump_stack.c:122<br /> print_report mm/kasan/report.c:521<br /> kasan_report mm/kasan/report.c:634<br /> kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528<br /> kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605<br /> kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656<br /> kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684<br /> kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733<br /> __handle_irq_event_percpu kernel/irq/handle.c:158<br /> handle_irq_event kernel/irq/handle.c:210<br /> handle_edge_irq kernel/irq/chip.c:833<br /> __common_interrupt arch/x86/kernel/irq.c:296<br /> common_interrupt arch/x86/kernel/irq.c:286<br /> <br /> <br /> Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seq<br /> numbers&amp;#39; generation that&amp;#39;s not the case - we&amp;#39;re free to calculate them as<br /> would be more convenient, not taking tx max count into account. The only<br /> downside is that the size of echo_skb[] should correspond to the max seq<br /> number (not tx max count), so in some situations a bit more memory would<br /> be consumed than could be.<br /> <br /> Thus make the size of the underlying echo_skb[] sufficient for the rounded<br /> max tx value.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vivid: Change the siize of the composing<br /> <br /> syzkaller found a bug:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]<br /> BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705<br /> Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304<br /> <br /> CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> kasan_check_range+0x282/0x290 mm/kasan/generic.c:189<br /> __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106<br /> tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]<br /> tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705<br /> vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline]<br /> vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629<br /> vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767<br /> kthread+0x7a9/0x920 kernel/kthread.c:464<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> The composition size cannot be larger than the size of fmt_cap_rect.<br /> So execute v4l2_rect_map_inside() even if has_compose_cap == 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Cleanup after an allocation error<br /> <br /> When allocation failures are not cleaned up by the driver, further<br /> allocation errors will be false-positives, which will cause buffers to<br /> remain uninitialized and cause NULL pointer dereferences.<br /> Ensure proper cleanup of failed allocations to prevent these issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: avoid kernel BUG for encrypted inode with unaligned file size<br /> <br /> The generic/397 test hits a BUG_ON for the case of encrypted inode with<br /> unaligned file size (for example, 33K or 1K):<br /> <br /> [ 877.737811] run fstests generic/397 at 2025-01-03 12:34:40<br /> [ 877.875761] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 877.876130] libceph: client4614 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 877.991965] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 877.992334] libceph: client4617 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.017234] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 878.017594] libceph: client4620 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.031394] xfs_io (pid 18988) is setting deprecated v1 encryption policy; recommend upgrading to v2.<br /> [ 878.054528] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 878.054892] libceph: client4623 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.070287] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 878.070704] libceph: client4626 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.264586] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 878.265258] libceph: client4629 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.374578] -----------[ cut here ]------------<br /> [ 878.374586] kernel BUG at net/ceph/messenger.c:1070!<br /> [ 878.375150] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 878.378145] CPU: 2 UID: 0 PID: 4759 Comm: kworker/2:9 Not tainted 6.13.0-rc5+ #1<br /> [ 878.378969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 878.380167] Workqueue: ceph-msgr ceph_con_workfn<br /> [ 878.381639] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50<br /> [ 878.382152] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90<br /> [ 878.383928] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287<br /> [ 878.384447] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000<br /> [ 878.385129] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378<br /> [ 878.385839] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000<br /> [ 878.386539] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030<br /> [ 878.387203] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001<br /> [ 878.387877] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000<br /> [ 878.388663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 878.389212] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0<br /> [ 878.389921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 878.390620] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 878.391307] PKRU: 55555554<br /> [ 878.391567] Call Trace:<br /> [ 878.391807] <br /> [ 878.392021] ? show_regs+0x71/0x90<br /> [ 878.392391] ? die+0x38/0xa0<br /> [ 878.392667] ? do_trap+0xdb/0x100<br /> [ 878.392981] ? do_error_trap+0x75/0xb0<br /> [ 878.393372] ? ceph_msg_data_cursor_init+0x42/0x50<br /> [ 878.393842] ? exc_invalid_op+0x53/0x80<br /> [ 878.394232] ? ceph_msg_data_cursor_init+0x42/0x50<br /> [ 878.394694] ? asm_exc_invalid_op+0x1b/0x20<br /> [ 878.395099] ? ceph_msg_data_cursor_init+0x42/0x50<br /> [ 878.395583] ? ceph_con_v2_try_read+0xd16/0x2220<br /> [ 878.396027] ? _raw_spin_unlock+0xe/0x40<br /> [ 878.396428] ? raw_spin_rq_unlock+0x10/0x40<br /> [ 878.396842] ? finish_task_switch.isra.0+0x97/0x310<br /> [ 878.397338] ? __schedule+0x44b/0x16b0<br /> [ 878.397738] ceph_con_workfn+0x326/0x750<br /> [ 878.398121] process_one_work+0x188/0x3d0<br /> [ 878.398522] ? __pfx_worker_thread+0x10/0x10<br /> [ 878.398929] worker_thread+0x2b5/0x3c0<br /> [ 878.399310] ? __pfx_worker_thread+0x10/0x10<br /> [ 878.399727] kthread+0xe1/0x120<br /> [ 878.400031] ? __pfx_kthread+0x10/0x10<br /> [ 878.400431] ret_from_fork+0x43/0x70<br /> [ 878.400771] ? __pfx_kthread+0x10/0x10<br /> [ 878.401127] ret_from_fork_asm+0x1a/0x30<br /> [ 878.401543] <br /> [ 878.401760] Modules l<br /> ---truncated---