Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit()<br /> <br /> When trace_get_event_file() failed, gen_kretprobe_test will be assigned<br /> as the error code. If module kprobe_event_gen_test is removed now, the<br /> null pointer dereference will happen in kprobe_event_gen_test_exit().<br /> Check if gen_kprobe_test or gen_kretprobe_test is error code or NULL<br /> before dereference them.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000012<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 3 PID: 2210 Comm: modprobe Not tainted<br /> 6.1.0-rc1-00171-g2159299a3b74-dirty #217<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test]<br /> Code: Unable to access opcode bytes at 0xffffffff9ffffff2.<br /> RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246<br /> RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000<br /> RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c<br /> RBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0<br /> R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800<br /> R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __x64_sys_delete_module+0x206/0x380<br /> ? lockdep_hardirqs_on_prepare+0xd8/0x190<br /> ? syscall_enter_from_user_mode+0x1c/0x50<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit()<br /> <br /> When test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it<br /> will goto delete, which will call kprobe_event_delete() and release the<br /> corresponding resource. However, the trace_array in gen_kretprobe_test<br /> will point to the invalid resource. Set gen_kretprobe_test to NULL<br /> after called kprobe_event_delete() to prevent null-ptr-deref.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000070<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 0 PID: 246 Comm: modprobe Tainted: G W<br /> 6.1.0-rc1-00174-g9522dc5c87da-dirty #248<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0<br /> Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c<br /> 01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 8b 65<br /> 70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f<br /> RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000<br /> RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001<br /> R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064<br /> R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000<br /> FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __ftrace_set_clr_event+0x3e/0x60<br /> trace_array_set_clr_event+0x35/0x50<br /> ? 0xffffffffa0000000<br /> kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test]<br /> __x64_sys_delete_module+0x206/0x380<br /> ? lockdep_hardirqs_on_prepare+0xd8/0x190<br /> ? syscall_enter_from_user_mode+0x1c/0x50<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f89eeb061b7

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()<br /> <br /> `struct vmci_event_qp` allocated by qp_notify_peer() contains padding,<br /> which may carry uninitialized data to the userspace, as observed by<br /> KMSAN:<br /> <br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121<br /> instrument_copy_to_user ./include/linux/instrumented.h:121<br /> _copy_to_user+0x5f/0xb0 lib/usercopy.c:33<br /> copy_to_user ./include/linux/uaccess.h:169<br /> vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431<br /> vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925<br /> vfs_ioctl fs/ioctl.c:51<br /> ...<br /> <br /> Uninit was stored to memory at:<br /> kmemdup+0x74/0xb0 mm/util.c:131<br /> dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271<br /> vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339<br /> qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479<br /> qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662<br /> qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750<br /> vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940<br /> vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488<br /> vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927<br /> ...<br /> <br /> Local variable ev created at:<br /> qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456<br /> qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662<br /> qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750<br /> <br /> Bytes 28-31 of 48 are uninitialized<br /> Memory access of size 48 starts at ffff888035155e00<br /> Data copied to user address 0000000020000100<br /> <br /> Use memset() to prevent the infoleaks.<br /> <br /> Also speculatively fix qp_notify_peer_local(), which may suffer from the<br /> same problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: zfcp: Fix double free of FSF request when qdio send fails<br /> <br /> We used to use the wrong type of integer in &amp;#39;zfcp_fsf_req_send()&amp;#39; to cache<br /> the FSF request ID when sending a new FSF request. This is used in case the<br /> sending fails and we need to remove the request from our internal hash<br /> table again (so we don&amp;#39;t keep an invalid reference and use it when we free<br /> the request again).<br /> <br /> In &amp;#39;zfcp_fsf_req_send()&amp;#39; we used to cache the ID as &amp;#39;int&amp;#39; (signed and 32<br /> bit wide), but the rest of the zfcp code (and the firmware specification)<br /> handles the ID as &amp;#39;unsigned long&amp;#39;/&amp;#39;u64&amp;#39; (unsigned and 64 bit wide [s390x<br /> ELF ABI]). For one this has the obvious problem that when the ID grows<br /> past 32 bit (this can happen reasonably fast) it is truncated to 32 bit<br /> when storing it in the cache variable and so doesn&amp;#39;t match the original ID<br /> anymore. The second less obvious problem is that even when the original ID<br /> has not yet grown past 32 bit, as soon as the 32nd bit is set in the<br /> original ID (0x80000000 = 2&amp;#39;147&amp;#39;483&amp;#39;648) we will have a mismatch when we<br /> cast it back to &amp;#39;unsigned long&amp;#39;. As the cached variable is of a signed<br /> type, the compiler will choose a sign-extending instruction to load the 32<br /> bit variable into a 64 bit register (e.g.: &amp;#39;lgf %r11,188(%r15)&amp;#39;). So once<br /> we pass the cached variable into &amp;#39;zfcp_reqlist_find_rm()&amp;#39; to remove the<br /> request again all the leading zeros will be flipped to ones to extend the<br /> sign and won&amp;#39;t match the original ID anymore (this has been observed in<br /> practice).<br /> <br /> If we can&amp;#39;t successfully remove the request from the hash table again after<br /> &amp;#39;zfcp_qdio_send()&amp;#39; fails (this happens regularly when zfcp cannot notify<br /> the adapter about new work because the adapter is already gone during<br /> e.g. a ChpID toggle) we will end up with a double free. We unconditionally<br /> free the request in the calling function when &amp;#39;zfcp_fsf_req_send()&amp;#39; fails,<br /> but because the request is still in the hash table we end up with a stale<br /> memory reference, and once the zfcp adapter is either reset during recovery<br /> or shutdown we end up freeing the same memory twice.<br /> <br /> The resulting stack traces vary depending on the kernel and have no direct<br /> correlation to the place where the bug occurs. Here are three examples that<br /> have been seen in practice:<br /> <br /> list_del corruption. next-&gt;prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:62!<br /> monitor event: 0040 ilc:2 [#1] PREEMPT SMP<br /> Modules linked in: ...<br /> CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded<br /> Hardware name: ...<br /> Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)<br /> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3<br /> Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6<br /> 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8<br /> 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800<br /> 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70<br /> Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336<br /> 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8<br /> #00000003cbeea1f4: af000000 mc 0,0<br /> &gt;00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78<br /> 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48<br /> 00000003cbeea204: b9040043 lgr %r4,%r3<br /> 00000003cbeea208: b9040051 lgr %r5,%r1<br /> 00000003cbeea20c: b9040032 lgr %r3,%r2<br /> Call Trace:<br /> [] __list_del_entry_valid+0x98/0x140<br /> ([] __list_del_entry_valid+0x94/0x140)<br /> [] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]<br /> [] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]<br /> ---truncated---

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.