Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kprobes: Skip clearing aggrprobe&amp;#39;s post_handler in kprobe-on-ftrace case<br /> <br /> In __unregister_kprobe_top(), if the currently unregistered probe has<br /> post_handler but other child probes of the aggrprobe do not have<br /> post_handler, the post_handler of the aggrprobe is cleared. If this is<br /> a ftrace-based probe, there is a problem. In later calls to<br /> disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is<br /> NULL. But we&amp;#39;re armed with kprobe_ipmodify_ops. This triggers a WARN in<br /> __disarm_kprobe_ftrace() and may even cause use-after-free:<br /> <br /> Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2)<br /> WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0<br /> Modules linked in: testKprobe_007(-)<br /> CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18<br /> [...]<br /> Call Trace:<br /> <br /> __disable_kprobe+0xcd/0xe0<br /> __unregister_kprobe_top+0x12/0x150<br /> ? mutex_lock+0xe/0x30<br /> unregister_kprobes.part.23+0x31/0xa0<br /> unregister_kprobe+0x32/0x40<br /> __x64_sys_delete_module+0x15e/0x260<br /> ? do_user_addr_fault+0x2cd/0x6b0<br /> do_syscall_64+0x3a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> For the kprobe-on-ftrace case, we keep the post_handler setting to<br /> identify this aggrprobe armed with kprobe_ipmodify_ops. This way we<br /> can disarm it correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()<br /> <br /> If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated<br /> by dev_set_name() need be freed. As comment of device_register() says, it<br /> should use put_device() to give up the reference in the error path. So fix<br /> this by calling put_device(), then the name can be freed in kobject_cleanup().<br /> The &amp;#39;tl_hba&amp;#39; will be freed in tcm_loop_release_adapter(), so it don&amp;#39;t need<br /> goto error label in this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling<br /> <br /> amd_pmu_enable_all() does:<br /> <br /> if (!test_bit(idx, cpuc-&gt;active_mask))<br /> continue;<br /> <br /> amd_pmu_enable_event(cpuc-&gt;events[idx]);<br /> <br /> A perf NMI of another event can come between these two steps. Perf NMI<br /> handler internally disables and enables _all_ events, including the one<br /> which nmi-intercepted amd_pmu_enable_all() was in process of enabling.<br /> If that unintentionally enabled event has very low sampling period and<br /> causes immediate successive NMI, causing the event to be throttled,<br /> cpuc-&gt;events[idx] and cpuc-&gt;active_mask gets cleared by x86_pmu_stop().<br /> This will result in amd_pmu_enable_event() getting called with event=NULL<br /> when amd_pmu_enable_all() resumes after handling the NMIs. This causes a<br /> kernel crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000198<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> [...]<br /> Call Trace:<br /> <br /> amd_pmu_enable_all+0x68/0xb0<br /> ctx_resched+0xd9/0x150<br /> event_function+0xb8/0x130<br /> ? hrtimer_start_range_ns+0x141/0x4a0<br /> ? perf_duration_warn+0x30/0x30<br /> remote_function+0x4d/0x60<br /> __flush_smp_call_function_queue+0xc4/0x500<br /> flush_smp_call_function_queue+0x11d/0x1b0<br /> do_idle+0x18f/0x2d0<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x121/0x160<br /> secondary_startup_64_no_verify+0xe5/0xeb<br /> <br /> <br /> amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler<br /> were recently added as part of BRS enablement but I&amp;#39;m not sure whether<br /> we really need them. We can just disable BRS in the beginning and enable<br /> it back while returning from NMI. This will solve the issue by not<br /> enabling those events whose active_masks are set but are not yet enabled<br /> in hw pmu.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Improve missing SIGTRAP checking<br /> <br /> To catch missing SIGTRAP we employ a WARN in __perf_event_overflow(),<br /> which fires if pending_sigtrap was already set: returning to user space<br /> without consuming pending_sigtrap, and then having the event fire again<br /> would re-enter the kernel and trigger the WARN.<br /> <br /> This, however, seemed to miss the case where some events not associated<br /> with progress in the user space task can fire and the interrupt handler<br /> runs before the IRQ work meant to consume pending_sigtrap (and generate<br /> the SIGTRAP).<br /> <br /> syzbot gifted us this stack trace:<br /> <br /> | WARNING: CPU: 0 PID: 3607 at kernel/events/core.c:9313 __perf_event_overflow<br /> | Modules linked in:<br /> | CPU: 0 PID: 3607 Comm: syz-executor100 Not tainted 6.1.0-rc2-syzkaller-00073-g88619e77b33d #0<br /> | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022<br /> | RIP: 0010:__perf_event_overflow+0x498/0x540 kernel/events/core.c:9313<br /> | <br /> | Call Trace:<br /> | <br /> | perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729<br /> | __run_hrtimer kernel/time/hrtimer.c:1685 [inline]<br /> | __hrtimer_run_queues+0x1c6/0xfb0 kernel/time/hrtimer.c:1749<br /> | hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811<br /> | local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1096 [inline]<br /> | __sysvec_apic_timer_interrupt+0x17c/0x640 arch/x86/kernel/apic/apic.c:1113<br /> | sysvec_apic_timer_interrupt+0x40/0xc0 arch/x86/kernel/apic/apic.c:1107<br /> | asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649<br /> | <br /> | <br /> <br /> In this case, syzbot produced a program with event type<br /> PERF_TYPE_SOFTWARE and config PERF_COUNT_SW_CPU_CLOCK. The hrtimer<br /> manages to fire again before the IRQ work got a chance to run, all while<br /> never having returned to user space.<br /> <br /> Improve the WARN to check for real progress in user space: approximate<br /> this by storing a 32-bit hash of the current IP into pending_sigtrap,<br /> and if an event fires while pending_sigtrap still matches the previous<br /> IP, we assume no progress (false negatives are possible given we could<br /> return to user space and trigger again on the same IP).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Drop fpregs lock before inheriting FPU permissions<br /> <br /> Mike Galbraith reported the following against an old fork of preempt-rt<br /> but the same issue also applies to the current preempt-rt tree.<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> Preemption disabled at:<br /> fpu_clone<br /> CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased)<br /> Call Trace:<br /> <br /> dump_stack_lvl<br /> ? fpu_clone<br /> __might_resched<br /> rt_spin_lock<br /> fpu_clone<br /> ? copy_thread<br /> ? copy_process<br /> ? shmem_alloc_inode<br /> ? kmem_cache_alloc<br /> ? kernel_clone<br /> ? __do_sys_clone<br /> ? do_syscall_64<br /> ? __x64_sys_rt_sigprocmask<br /> ? syscall_exit_to_user_mode<br /> ? do_syscall_64<br /> ? syscall_exit_to_user_mode<br /> ? do_syscall_64<br /> ? syscall_exit_to_user_mode<br /> ? do_syscall_64<br /> ? exc_page_fault<br /> ? entry_SYSCALL_64_after_hwframe<br /> <br /> <br /> Mike says:<br /> <br /> The splat comes from fpu_inherit_perms() being called under fpregs_lock(),<br /> and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()<br /> returning true despite static key __fpu_state_size_dynamic having never<br /> been enabled.<br /> <br /> Mike&amp;#39;s assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables<br /> preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This<br /> problem exists since commit<br /> <br /> 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features").<br /> <br /> Even though the original bug report should not have enabled the paths at<br /> all, the bug still exists.<br /> <br /> fpregs_lock is necessary when editing the FPU registers or a task&amp;#39;s FP<br /> state but it is not necessary for fpu_inherit_perms(). The only write<br /> of any FP state in fpu_inherit_perms() is for the new child which is<br /> not running yet and cannot context switch or be borrowed by a kernel<br /> thread yet. Hence, fpregs_lock is not protecting anything in the new<br /> child until clone() completes and can be dropped earlier. The siglock<br /> still needs to be acquired by fpu_inherit_perms() as the read of the<br /> parent&amp;#39;s permissions has to be serialised.<br /> <br /> [ bp: Cleanup splat. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/amd/uncore: Fix memory leak for events array<br /> <br /> When a CPU comes online, the per-CPU NB and LLC uncore contexts are<br /> freed but not the events array within the context structure. This<br /> causes a memory leak as identified by the kmemleak detector.<br /> <br /> [...]<br /> unreferenced object 0xffff8c5944b8e320 (size 32):<br /> comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] amd_uncore_cpu_up_prepare+0xaf/0x230<br /> [] cpuhp_invoke_callback+0x2cf/0x470<br /> [] cpuhp_issue_call+0x14d/0x170<br /> [] __cpuhp_setup_state_cpuslocked+0x11e/0x330<br /> [] __cpuhp_setup_state+0x6b/0x110<br /> [] amd_uncore_init+0x260/0x321<br /> [] do_one_initcall+0x3f/0x1f0<br /> [] kernel_init_freeable+0x1ca/0x212<br /> [] kernel_init+0x11/0x120<br /> [] ret_from_fork+0x22/0x30<br /> unreferenced object 0xffff8c5944b8dd40 (size 64):<br /> comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] amd_uncore_cpu_up_prepare+0x183/0x230<br /> [] cpuhp_invoke_callback+0x2cf/0x470<br /> [] cpuhp_issue_call+0x14d/0x170<br /> [] __cpuhp_setup_state_cpuslocked+0x11e/0x330<br /> [] __cpuhp_setup_state+0x6b/0x110<br /> [] amd_uncore_init+0x260/0x321<br /> [] do_one_initcall+0x3f/0x1f0<br /> [] kernel_init_freeable+0x1ca/0x212<br /> [] kernel_init+0x11/0x120<br /> [] ret_from_fork+0x22/0x30<br /> [...]<br /> <br /> Fix the problem by freeing the events array before freeing the uncore<br /> context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/sgx: Add overflow check in sgx_validate_offset_length()<br /> <br /> sgx_validate_offset_length() function verifies "offset" and "length"<br /> arguments provided by userspace, but was missing an overflow check on<br /> their addition. Add it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: properly pin the parent in blkcg_css_online<br /> <br /> blkcg_css_online is supposed to pin the blkcg of the parent, but<br /> 397c9f46ee4d refactored things and along the way, changed it to pin the<br /> css instead. This results in extra pins, and we end up leaking blkcgs<br /> and cgroups.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()<br /> <br /> pci_get_device() will increase the reference count for the returned<br /> pci_dev. We need to use pci_dev_put() to decrease the reference count<br /> before amd_probe() returns. There is no problem for the &amp;#39;smbus_dev ==<br /> NULL&amp;#39; branch because pci_dev_put() can also handle the NULL input<br /> parameter case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm ioctl: fix misbehavior if list_versions races with module loading<br /> <br /> __list_versions will first estimate the required space using the<br /> "dm_target_iterate(list_version_get_needed, &amp;needed)" call and then will<br /> fill the space using the "dm_target_iterate(list_version_get_info,<br /> &amp;iter_info)" call. Each of these calls locks the targets using the<br /> "down_read(&amp;_lock)" and "up_read(&amp;_lock)" calls, however between the first<br /> and second "dm_target_iterate" there is no lock held and the target<br /> modules can be loaded at this point, so the second "dm_target_iterate"<br /> call may need more space than what was the first "dm_target_iterate"<br /> returned.<br /> <br /> The code tries to handle this overflow (see the beginning of<br /> list_version_get_info), however this handling is incorrect.<br /> <br /> The code sets "param-&gt;data_size = param-&gt;data_start + needed" and<br /> "iter_info.end = (char *)vers+len" - "needed" is the size returned by the<br /> first dm_target_iterate call; "len" is the size of the buffer allocated by<br /> userspace.<br /> <br /> "len" may be greater than "needed"; in this case, the code will write up<br /> to "len" bytes into the buffer, however param-&gt;data_size is set to<br /> "needed", so it may write data past the param-&gt;data_size value. The ioctl<br /> interface copies only up to param-&gt;data_size into userspace, thus part of<br /> the result will be truncated.<br /> <br /> Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this<br /> guarantees that the second "dm_target_iterate" call will write only up to<br /> the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it<br /> overflows the "needed" space - in this case, userspace will allocate a<br /> larger buffer and retry.<br /> <br /> Note that there is also a bug in list_version_get_needed - we need to add<br /> "strlen(tt-&gt;name) + 1" to the needed size, not "strlen(tt-&gt;name)".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open()<br /> <br /> snd_usbmidi_output_open() has a check of the NULL port with<br /> snd_BUG_ON(). snd_BUG_ON() was used as this shouldn&amp;#39;t have happened,<br /> but in reality, the NULL port may be seen when the device gives an<br /> invalid endpoint setup at the descriptor, hence the driver skips the<br /> allocation. That is, the check itself is valid and snd_BUG_ON()<br /> should be dropped from there. Otherwise it&amp;#39;s confusing as if it were<br /> a real bug, as recently syzbot stumbled on it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix optc2_configure warning on dcn314<br /> <br /> [Why]<br /> dcn314 uses optc2_configure_crc() that wraps<br /> optc1_configure_crc() + set additional registers<br /> not applicable to dcn314.<br /> It&amp;#39;s not critical but when used leads to warning like:<br /> WARNING: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c<br /> Call Trace:<br /> <br /> generic_reg_set_ex+0x6d/0xe0 [amdgpu]<br /> optc2_configure_crc+0x60/0x80 [amdgpu]<br /> dc_stream_configure_crc+0x129/0x150 [amdgpu]<br /> amdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu]<br /> <br /> [How]<br /> Use optc1_configure_crc() directly