Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()<br /> <br /> Change num_ghes from int to unsigned int, preventing an overflow<br /> and causing subsequent vmalloc() to fail.<br /> <br /> The overflow happens in ghes_estatus_pool_init() when calculating<br /> len during execution of the statement below as both multiplication<br /> operands here are signed int:<br /> <br /> len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);<br /> <br /> The following call trace is observed because of this bug:<br /> <br /> [ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1<br /> [ 9.317131] Call Trace:<br /> [ 9.317134] <br /> [ 9.317137] dump_stack_lvl+0x49/0x5f<br /> [ 9.317145] dump_stack+0x10/0x12<br /> [ 9.317146] warn_alloc.cold+0x7b/0xdf<br /> [ 9.317150] ? __device_attach+0x16a/0x1b0<br /> [ 9.317155] __vmalloc_node_range+0x702/0x740<br /> [ 9.317160] ? device_add+0x17f/0x920<br /> [ 9.317164] ? dev_set_name+0x53/0x70<br /> [ 9.317166] ? platform_device_add+0xf9/0x240<br /> [ 9.317168] __vmalloc_node+0x49/0x50<br /> [ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0<br /> [ 9.317176] vmalloc+0x21/0x30<br /> [ 9.317177] ghes_estatus_pool_init+0x43/0xa0<br /> [ 9.317179] acpi_hest_init+0x129/0x19c<br /> [ 9.317185] acpi_init+0x434/0x4a4<br /> [ 9.317188] ? acpi_sleep_proc_init+0x2a/0x2a<br /> [ 9.317190] do_one_initcall+0x48/0x200<br /> [ 9.317195] kernel_init_freeable+0x221/0x284<br /> [ 9.317200] ? rest_init+0xe0/0xe0<br /> [ 9.317204] kernel_init+0x1a/0x130<br /> [ 9.317205] ret_from_fork+0x22/0x30<br /> [ 9.317208] <br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: fix memory leak in query_regdb_file()<br /> <br /> In the function query_regdb_file() the alpha2 parameter is duplicated<br /> using kmemdup() and subsequently freed in regdb_fw_cb(). However,<br /> request_firmware_nowait() can fail without calling regdb_fw_cb() and<br /> thus leak memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix panic on frag_list with mixed head alloc types<br /> <br /> Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when<br /> splitting gso_size mangled skb having linear-headed frag_list"), it is<br /> allowed to change gso_size of a GRO packet. However, that commit assumes<br /> that "checking the first list_skb member suffices; i.e if either of the<br /> list_skb members have non head_frag head, then the first one has too".<br /> <br /> It turns out this assumption does not hold. We&amp;#39;ve seen BUG_ON being hit<br /> in skb_segment when skbs on the frag_list had differing head_frag with<br /> the vmxnet3 driver. This happens because __netdev_alloc_skb and<br /> __napi_alloc_skb can return a skb that is page backed or kmalloced<br /> depending on the requested size. As the result, the last small skb in<br /> the GRO packet can be kmalloced.<br /> <br /> There are three different locations where this can be fixed:<br /> <br /> (1) We could check head_frag in GRO and not allow GROing skbs with<br /> different head_frag. However, that would lead to performance<br /> regression on normal forward paths with unmodified gso_size, where<br /> !head_frag in the last packet is not a problem.<br /> <br /> (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating<br /> that NETIF_F_SG is undesirable. That would need to eat a bit in<br /> sk_buff. Furthermore, that flag can be unset when all skbs on the<br /> frag_list are page backed. To retain good performance,<br /> bpf_skb_net_grow/shrink would have to walk the frag_list.<br /> <br /> (3) Walk the frag_list in skb_segment when determining whether<br /> NETIF_F_SG should be cleared. This of course slows things down.<br /> <br /> This patch implements (3). To limit the performance impact in<br /> skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set<br /> that have gso_size changed. Normal paths thus will not hit it.<br /> <br /> We could check only the last skb but since we need to walk the whole<br /> list anyway, let&amp;#39;s stay on the safe side.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix the sk-&gt;sk_forward_alloc warning of sk_stream_kill_queues<br /> <br /> When running `test_sockmap` selftests, the following warning appears:<br /> <br /> WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> tcp_rcv_state_process+0xd28/0x1380<br /> ? tcp_v4_do_rcv+0x77/0x2c0<br /> tcp_v4_do_rcv+0x77/0x2c0<br /> __release_sock+0x106/0x130<br /> __tcp_close+0x1a7/0x4e0<br /> tcp_close+0x20/0x70<br /> inet_release+0x3c/0x80<br /> __sock_release+0x3a/0xb0<br /> sock_close+0x14/0x20<br /> __fput+0xa3/0x260<br /> task_work_run+0x59/0xb0<br /> exit_to_user_mode_prepare+0x1b3/0x1c0<br /> syscall_exit_to_user_mode+0x19/0x50<br /> do_syscall_64+0x48/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged<br /> while msg has more_data"), where I used msg-&gt;sg.size to replace the tosend,<br /> causing breakage:<br /> <br /> if (msg-&gt;apply_bytes &amp;&amp; msg-&gt;apply_bytes apply_bytes;