Vulnerabilities

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 /> 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 /> 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 /> bus: fsl-mc: fix double-free on mc_dev<br /> <br /> The blamed commit tried to simplify how the deallocations are done but,<br /> in the process, introduced a double-free on the mc_dev variable.<br /> <br /> In case the MC device is a DPRC, a new mc_bus is allocated and the<br /> mc_dev variable is just a reference to one of its fields. In this<br /> circumstance, on the error path only the mc_bus should be freed.<br /> <br /> This commit introduces back the following checkpatch warning which is a<br /> false-positive.<br /> <br /> WARNING: kfree(NULL) is safe and this check is probably not required<br /> + if (mc_bus)<br /> + kfree(mc_bus);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table<br /> <br /> The function atomctrl_initialize_mc_reg_table() and<br /> atomctrl_initialize_mc_reg_table_v2_2() does not check the return<br /> value of smu_atom_get_data_table(). If smu_atom_get_data_table()<br /> fails to retrieve vram_info, it returns NULL which is later<br /> dereferenced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: arm-ni: Fix missing platform_set_drvdata()<br /> <br /> Add missing platform_set_drvdata in arm_ni_probe(), otherwise<br /> calling platform_get_drvdata() in remove returns NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix buffer overflow in debugfs<br /> <br /> If the user tries to write more than 32 bytes then it results in memory<br /> corruption. Fortunately, this is debugfs so it&amp;#39;s limited to root users.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: avoid NULL pointer dereference in mt7996_set_monitor()<br /> <br /> The function mt7996_set_monitor() dereferences phy before<br /> the NULL sanity check.<br /> <br /> Fix this to avoid NULL pointer dereference by moving the<br /> dereference after the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btintel: Check dsbr size from EFI variable<br /> <br /> Since the size of struct btintel_dsbr is already known, we can just<br /> start there instead of querying the EFI variable size. If the final<br /> result doesn&amp;#39;t match what we expect also fail. This fixes a stack buffer<br /> overflow when the EFI variable is larger than struct btintel_dsbr.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-pci: Fix result size returned for the admin command completion<br /> <br /> The result size returned by virtio_pci_admin_dev_parts_get() is 8 bytes<br /> larger than the actual result data size. This occurs because the<br /> result_sg_size field of the command is filled with the result length<br /> from virtqueue_get_buf(), which includes both the data size and an<br /> additional 8 bytes of status.<br /> <br /> This oversized result size causes two issues:<br /> 1. The state transferred to the destination includes 8 bytes of extra<br /> data at the end.<br /> 2. The allocated buffer in the kernel may be smaller than the returned<br /> size, leading to failures when reading beyond the allocated size.<br /> <br /> The commit fixes this by subtracting the status size from the result of<br /> virtqueue_get_buf().<br /> <br /> This fix has been tested through live migrations with virtio-net,<br /> virtio-net-transitional, and virtio-blk devices.

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