Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Fix region HPA ordering validation<br /> <br /> Some regions may not have any address space allocated. Skip them when<br /> validating HPA order otherwise a crash like the following may result:<br /> <br /> devm_cxl_add_region: cxl_acpi cxl_acpi.0: decoder3.4: created region9<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [..]<br /> RIP: 0010:store_targetN+0x655/0x1740 [cxl_core]<br /> [..]<br /> Call Trace:<br /> <br /> kernfs_fop_write_iter+0x144/0x200<br /> vfs_write+0x24a/0x4d0<br /> ksys_write+0x69/0xf0<br /> do_syscall_64+0x3a/0x90<br /> <br /> store_targetN+0x655/0x1740:<br /> alloc_region_ref at drivers/cxl/core/region.c:676<br /> (inlined by) cxl_port_attach_region at drivers/cxl/core/region.c:850<br /> (inlined by) cxl_region_attach at drivers/cxl/core/region.c:1290<br /> (inlined by) attach_target at drivers/cxl/core/region.c:1410<br /> (inlined by) store_targetN at drivers/cxl/core/region.c:1453

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix use-after-free for dynamic ftrace_ops<br /> <br /> KASAN reported a use-after-free with ftrace ops [1]. It was found from<br /> vmcore that perf had registered two ops with the same content<br /> successively, both dynamic. After unregistering the second ops, a<br /> use-after-free occurred.<br /> <br /> In ftrace_shutdown(), when the second ops is unregistered, the<br /> FTRACE_UPDATE_CALLS command is not set because there is another enabled<br /> ops with the same content. Also, both ops are dynamic and the ftrace<br /> callback function is ftrace_ops_list_func, so the<br /> FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value<br /> of &amp;#39;command&amp;#39; will be 0 and ftrace_shutdown() will skip the rcu<br /> synchronization.<br /> <br /> However, ftrace may be activated. When the ops is released, another CPU<br /> may be accessing the ops. Add the missing synchronization to fix this<br /> problem.<br /> <br /> [1]<br /> BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]<br /> BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049<br /> Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468<br /> <br /> CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132<br /> show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x1b4/0x248 lib/dump_stack.c:118<br /> print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387<br /> __kasan_report mm/kasan/report.c:547 [inline]<br /> kasan_report+0x118/0x210 mm/kasan/report.c:564<br /> check_memory_region_inline mm/kasan/generic.c:187 [inline]<br /> __asan_load8+0x98/0xc0 mm/kasan/generic.c:253<br /> __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline]<br /> ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049<br /> ftrace_graph_call+0x0/0x4<br /> __might_sleep+0x8/0x100 include/linux/perf_event.h:1170<br /> __might_fault mm/memory.c:5183 [inline]<br /> __might_fault+0x58/0x70 mm/memory.c:5171<br /> do_strncpy_from_user lib/strncpy_from_user.c:41 [inline]<br /> strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139<br /> getname_flags+0xb0/0x31c fs/namei.c:149<br /> getname+0x2c/0x40 fs/namei.c:209<br /> [...]<br /> <br /> Allocated by task 14445:<br /> kasan_save_stack+0x24/0x50 mm/kasan/common.c:48<br /> kasan_set_track mm/kasan/common.c:56 [inline]<br /> __kasan_kmalloc mm/kasan/common.c:479 [inline]<br /> __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449<br /> kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493<br /> kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950<br /> kmalloc include/linux/slab.h:563 [inline]<br /> kzalloc include/linux/slab.h:675 [inline]<br /> perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230<br /> perf_event_alloc kernel/events/core.c:11733 [inline]<br /> __do_sys_perf_event_open kernel/events/core.c:11831 [inline]<br /> __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723<br /> __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723<br /> [...]<br /> <br /> Freed by task 14445:<br /> kasan_save_stack+0x24/0x50 mm/kasan/common.c:48<br /> kasan_set_track+0x24/0x34 mm/kasan/common.c:56<br /> kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358<br /> __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437<br /> __kasan_slab_free mm/kasan/common.c:445 [inline]<br /> kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446<br /> slab_free_hook mm/slub.c:1569 [inline]<br /> slab_free_freelist_hook mm/slub.c:1608 [inline]<br /> slab_free mm/slub.c:3179 [inline]<br /> kfree+0x12c/0xc10 mm/slub.c:4176<br /> perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434<br /> perf_event_alloc kernel/events/core.c:11733 [inline]<br /> __do_sys_perf_event_open kernel/events/core.c:11831 [inline]<br /> __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723<br /> [...]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()<br /> <br /> test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak<br /> when there is no failure. Move kfree(buf) from fail path to common path<br /> to prevent the memleak. The same reason and solution in<br /> test_gen_kretprobe_cmd().<br /> <br /> unreferenced object 0xffff888143b14000 (size 2048):<br /> comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s)<br /> hex dump (first 32 bytes):<br /> 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp<br /> 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] 0xffffffffa059006f<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x3006/0x3390<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> capabilities: fix potential memleak on error path from vfs_getxattr_alloc()<br /> <br /> In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to<br /> complete the memory allocation of tmpbuf, if we have completed<br /> the memory allocation of tmpbuf, but failed to call handler-&gt;get(...),<br /> there will be a memleak in below logic:<br /> <br /> |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...)<br /> | /* ^^^ alloc for tmpbuf */<br /> |-- value = krealloc(*xattr_value, error + 1, flags)<br /> | /* ^^^ alloc memory */<br /> |-- error = handler-&gt;get(handler, ...)<br /> | /* error! */<br /> |-- *xattr_value = value<br /> | /* xattr_value is &amp;tmpbuf (memory leak!) */<br /> <br /> So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it.<br /> <br /> [PM: subject line and backtrace tweaks]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache<br /> <br /> Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive.<br /> Not checking the active flag during refresh is particularly egregious, as<br /> KVM can end up with a valid, inactive cache, which can lead to a variety<br /> of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing<br /> an mmu_notifier invalidation due to the cache not being on the list of<br /> gfns to invalidate.<br /> <br /> Note, "active" needs to be set if and only if the cache is on the list<br /> of caches, i.e. is reachable via mmu_notifier events. If a relevant<br /> mmu_notifier event occurs while the cache is "active" but not on the<br /> list, KVM will not acquire the cache&amp;#39;s lock and so will not serailize<br /> the mmu_notifier event with active users and/or kvm_gpc_refresh().<br /> <br /> A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND<br /> can be exploited to trigger the bug.<br /> <br /> 1. Deactivate shinfo cache:<br /> <br /> kvm_xen_hvm_set_attr<br /> case KVM_XEN_ATTR_TYPE_SHARED_INFO<br /> kvm_gpc_deactivate<br /> kvm_gpc_unmap<br /> gpc-&gt;valid = false<br /> gpc-&gt;khva = NULL<br /> gpc-&gt;active = false<br /> <br /> Result: active = false, valid = false<br /> <br /> 2. Cause cache refresh:<br /> <br /> kvm_arch_vm_ioctl<br /> case KVM_XEN_HVM_EVTCHN_SEND<br /> kvm_xen_hvm_evtchn_send<br /> kvm_xen_set_evtchn<br /> kvm_xen_set_evtchn_fast<br /> kvm_gpc_check<br /> return -EWOULDBLOCK because !gpc-&gt;valid<br /> kvm_xen_set_evtchn_fast<br /> return -EWOULDBLOCK<br /> kvm_gpc_refresh<br /> hva_to_pfn_retry<br /> gpc-&gt;valid = true<br /> gpc-&gt;khva = not NULL<br /> <br /> Result: active = false, valid = true<br /> <br /> 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl<br /> KVM_XEN_ATTR_TYPE_SHARED_INFO:<br /> <br /> kvm_arch_vm_ioctl<br /> case KVM_XEN_HVM_EVTCHN_SEND<br /> kvm_xen_hvm_evtchn_send<br /> kvm_xen_set_evtchn<br /> kvm_xen_set_evtchn_fast<br /> read_lock gpc-&gt;lock<br /> kvm_xen_hvm_set_attr case<br /> KVM_XEN_ATTR_TYPE_SHARED_INFO<br /> mutex_lock kvm-&gt;lock<br /> kvm_xen_shared_info_init<br /> kvm_gpc_activate<br /> gpc-&gt;khva = NULL<br /> kvm_gpc_check<br /> [ Check passes because gpc-&gt;valid is<br /> still true, even though gpc-&gt;khva<br /> is already NULL. ]<br /> shinfo = gpc-&gt;khva<br /> pending_bits = shinfo-&gt;evtchn_pending<br /> CRASH: test_and_set_bit(..., pending_bits)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format<br /> <br /> On 64 bit host, if the guest doesn&amp;#39;t have X86_FEATURE_LM, KVM will<br /> access 16 gprs to 32-bit smram image, causing out-ouf-bound ram<br /> access.<br /> <br /> On 32 bit host, the rsm_load_state_64/enter_smm_save_state_64<br /> is compiled out, thus access overflow can&amp;#39;t happen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Initialize gfn_to_pfn_cache locks in dedicated helper<br /> <br /> Move the gfn_to_pfn_cache lock initialization to another helper and<br /> call the new helper during VM/vCPU creation. There are race<br /> conditions possible due to kvm_gfn_to_pfn_cache_init()&amp;#39;s<br /> ability to re-initialize the cache&amp;#39;s locks.<br /> <br /> For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and<br /> kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock.<br /> <br /> (thread 1) | (thread 2)<br /> |<br /> kvm_xen_set_evtchn_fast |<br /> read_lock_irqsave(&amp;gpc-&gt;lock, ...) |<br /> | kvm_gfn_to_pfn_cache_init<br /> | rwlock_init(&amp;gpc-&gt;lock)<br /> read_unlock_irqrestore(&amp;gpc-&gt;lock, ...) |<br /> <br /> Rename "cache_init" and "cache_destroy" to activate+deactivate to<br /> avoid implying that the cache really is destroyed/freed.<br /> <br /> Note, there more races in the newly named kvm_gpc_activate() that will<br /> be addressed separately.<br /> <br /> [sean: call out that this is a bug fix]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/tdx: Panic on bad configs that #VE on "private" memory access<br /> <br /> All normal kernel memory is "TDX private memory". This includes<br /> everything from kernel stacks to kernel text. Handling<br /> exceptions on arbitrary accesses to kernel memory is essentially<br /> impossible because they can happen in horribly nasty places like<br /> kernel entry/exit. But, TDX hardware can theoretically _deliver_<br /> a virtualization exception (#VE) on any access to private memory.<br /> <br /> But, it&amp;#39;s not as bad as it sounds. TDX can be configured to never<br /> deliver these exceptions on private memory with a "TD attribute"<br /> called ATTR_SEPT_VE_DISABLE. The guest has no way to *set* this<br /> attribute, but it can check it.<br /> <br /> Ensure ATTR_SEPT_VE_DISABLE is set in early boot. panic() if it<br /> is unset. There is no sane way for Linux to run with this<br /> attribute clear so a panic() is appropriate.<br /> <br /> There&amp;#39;s small window during boot before the check where kernel<br /> has an early #VE handler. But the handler is only for port I/O<br /> and will also panic() as soon as it sees any other #VE, such as<br /> a one generated by a private memory access.<br /> <br /> [ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo().<br /> Add Kirill&amp;#39;s tested-by because I made changes since<br /> he wrote this. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters()<br /> <br /> On some machines the number of listed CPUs may be bigger than the actual<br /> CPUs that exist. The tracing subsystem allocates a per_cpu directory with<br /> access to the per CPU ring buffer via a cpuX file. But to save space, the<br /> ring buffer will only allocate buffers for online CPUs, even though the<br /> CPU array will be as big as the nr_cpu_ids.<br /> <br /> With the addition of waking waiters on the ring buffer when closing the<br /> file, the ring_buffer_wake_waiters() now needs to make sure that the<br /> buffer is allocated (with the irq_work allocated with it) before trying to<br /> wake waiters, as it will cause a NULL pointer dereference.<br /> <br /> While debugging this, I added a NULL check for the buffer itself (which is<br /> OK to do), and also NULL pointer checks against buffer-&gt;buffers (which is<br /> not fine, and will WARN) as well as making sure the CPU number passed in<br /> is within the nr_cpu_ids (which is also not fine if it isn&amp;#39;t).<br /> <br /> <br /> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: entry: avoid kprobe recursion<br /> <br /> The cortex_a76_erratum_1463225_debug_handler() function is called when<br /> handling debug exceptions (and synchronous exceptions from BRK<br /> instructions), and so is called when a probed function executes. If the<br /> compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it<br /> can be probed.<br /> <br /> If cortex_a76_erratum_1463225_debug_handler() is probed, any debug<br /> exception or software breakpoint exception will result in recursive<br /> exceptions leading to a stack overflow. This can be triggered with the<br /> ftrace multiple_probes selftest, and as per the example splat below.<br /> <br /> This is a regression caused by commit:<br /> <br /> 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround")<br /> <br /> ... which removed the NOKPROBE_SYMBOL() annotation associated with the<br /> function.<br /> <br /> My intent was that cortex_a76_erratum_1463225_debug_handler() would be<br /> inlined into its caller, el1_dbg(), which is marked noinstr and cannot<br /> be probed. Mark cortex_a76_erratum_1463225_debug_handler() as<br /> __always_inline to ensure this.<br /> <br /> Example splat prior to this patch (with recursive entries elided):<br /> <br /> | # echo p cortex_a76_erratum_1463225_debug_handler &gt; /sys/kernel/debug/tracing/kprobe_events<br /> | # echo p do_el0_svc &gt;&gt; /sys/kernel/debug/tracing/kprobe_events<br /> | # echo 1 &gt; /sys/kernel/debug/tracing/events/kprobes/enable<br /> | Insufficient stack space to handle exception!<br /> | ESR: 0x0000000096000047 -- DABT (current EL)<br /> | FAR: 0xffff800009cefff0<br /> | Task stack: [0xffff800009cf0000..0xffff800009cf4000]<br /> | IRQ stack: [0xffff800008000000..0xffff800008004000]<br /> | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0]<br /> | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : arm64_enter_el1_dbg+0x4/0x20<br /> | lr : el1_dbg+0x24/0x5c<br /> | sp : ffff800009cf0000<br /> | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000<br /> | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068<br /> | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000<br /> | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0<br /> | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000<br /> | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4<br /> | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040<br /> | Kernel panic - not syncing: kernel stack overflow<br /> | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2<br /> | Hardware name: linux,dummy-virt (DT)<br /> | Call trace:<br /> | dump_backtrace+0xe4/0x104<br /> | show_stack+0x18/0x4c<br /> | dump_stack_lvl+0x64/0x7c<br /> | dump_stack+0x18/0x38<br /> | panic+0x14c/0x338<br /> | test_taint+0x0/0x2c<br /> | panic_bad_stack+0x104/0x118<br /> | handle_bad_stack+0x34/0x48<br /> | __bad_stack+0x78/0x7c<br /> | arm64_enter_el1_dbg+0x4/0x20<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> ...<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> ...<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | do_el0_svc+0x0/0x28<br /> | el0t_64_sync_handler+0x84/0xf0<br /> | el0t_64_sync+0x18c/0x190<br /> | Kernel Offset: disabled<br /> | CPU features: 0x0080,00005021,19001080<br /> | Memory Limit: none<br /> | ---[ end Kernel panic - not syncing: kernel stack overflow ]---<br /> <br /> With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined<br /> into el1_dbg(), and el1_dbg() cannot be probed:<br /> <br /> | # echo p cortex_a76_erratum_1463225_debug_handler &gt; /sys/kernel/debug/tracing/kprobe_events<br /> | sh: write error: No such file or directory<br /> | # grep -w cortex_a76_errat<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: meson: vdec: fix possible refcount leak in vdec_probe()<br /> <br /> v4l2_device_unregister need to be called to put the refcount got by<br /> v4l2_device_register when vdec_probe fails or vdec_remove is called.