Vulnerabilities

The Couchbase .NET SDK (client library) before 3.7.1 does not properly enable hostname verification for TLS certificates. In fact, the SDK was also using IP addresses instead of hostnames due to a configuration option that was incorrectly enabled by default.

The Ultra Addons for Contact Form 7 plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'save_options' function in all versions up to, and including, 3.5.12. This makes it possible for authenticated attackers, with Administrator-level access and above, to upload arbitrary files on the affected site's server which may make remote code execution possible.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: set UXN on swapper page tables<br /> <br /> [ This issue was fixed upstream by accident in c3cee924bd85 ("arm64:<br /> head: cover entire kernel image in initial ID map") as part of a<br /> large refactoring of the arm64 boot flow. This simple fix is therefore<br /> preferred for -stable backporting ]<br /> <br /> On a system that implements FEAT_EPAN, read/write access to the idmap<br /> is denied because UXN is not set on the swapper PTEs. As a result,<br /> idmap_kpti_install_ng_mappings panics the kernel when accessing<br /> __idmap_kpti_flag. Fix it by setting UXN on these PTEs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: arm64/poly1305 - fix a read out-of-bound<br /> <br /> A kasan error was reported during fuzzing:<br /> <br /> BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]<br /> Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715<br /> CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1<br /> Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019<br /> Call trace:<br /> dump_backtrace+0x0/0x394<br /> show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x158/0x1e4 lib/dump_stack.c:118<br /> print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387<br /> __kasan_report+0xe0/0x140 mm/kasan/report.c:547<br /> kasan_report+0x44/0xe0 mm/kasan/report.c:564<br /> check_memory_region_inline mm/kasan/generic.c:187 [inline]<br /> __asan_load4+0x94/0xd0 mm/kasan/generic.c:252<br /> neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]<br /> neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]<br /> neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]<br /> crypto_shash_update crypto/shash.c:131 [inline]<br /> shash_finup_unaligned+0x84/0x15c crypto/shash.c:179<br /> crypto_shash_finup+0x8c/0x140 crypto/shash.c:193<br /> shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201<br /> crypto_shash_digest+0xa4/0xfc crypto/shash.c:217<br /> crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229<br /> essiv_skcipher_setkey+0x164/0x200 [essiv]<br /> crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612<br /> skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305<br /> alg_setkey+0x114/0x2a0 crypto/af_alg.c:220<br /> alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253<br /> __sys_setsockopt+0x190/0x2e0 net/socket.c:2123<br /> __do_sys_setsockopt net/socket.c:2134 [inline]<br /> __se_sys_setsockopt net/socket.c:2131 [inline]<br /> __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131<br /> __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]<br /> invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48<br /> el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155<br /> do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217<br /> el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353<br /> el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369<br /> el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683<br /> <br /> This error can be reproduced by the following code compiled as ko on a<br /> system with kasan enabled:<br /> <br /> #include <br /> #include <br /> #include <br /> #include <br /> <br /> char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07"<br /> "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"<br /> "\x10\x11\x12\x13\x14\x15\x16\x17"<br /> "\x18\x19\x1a\x1b\x1c\x1d\x1e";<br /> <br /> int init(void)<br /> {<br /> struct crypto_shash *tfm = NULL;<br /> char *data = NULL, *out = NULL;<br /> <br /> tfm = crypto_alloc_shash("poly1305", 0, 0);<br /> data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL);<br /> out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL);<br /> memcpy(data, test_data, POLY1305_KEY_SIZE - 1);<br /> crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out);<br /> <br /> kfree(data);<br /> kfree(out);<br /> return 0;<br /> }<br /> <br /> void deinit(void)<br /> {<br /> }<br /> <br /> module_init(init)<br /> module_exit(deinit)<br /> MODULE_LICENSE("GPL");<br /> <br /> The root cause of the bug sits in neon_poly1305_blocks. The logic<br /> neon_poly1305_blocks() performed is that if it was called with both s[]<br /> and r[] uninitialized, it will first try to initialize them with the<br /> data from the first "block" that it believed to be 32 bytes in length.<br /> First 16 bytes are used as the key and the next 16 bytes for s[]. This<br /> would lead to the aforementioned read out-of-bound. However, after<br /> calling poly1305_init_arch(), only 16 bytes were deducted from the input<br /> and s[] is initialized yet again with the following 16 bytes. The second<br /> initialization of s[] is certainly redundent which indicates that the<br /> first initialization should be for r[] only.<br /> <br /> This patch fixes the issue by calling poly1305_init_arm64() instead o<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: set UXN on swapper page tables<br /> <br /> [ This issue was fixed upstream by accident in c3cee924bd85 ("arm64:<br /> head: cover entire kernel image in initial ID map") as part of a<br /> large refactoring of the arm64 boot flow. This simple fix is therefore<br /> preferred for -stable backporting ]<br /> <br /> On a system that implements FEAT_EPAN, read/write access to the idmap<br /> is denied because UXN is not set on the swapper PTEs. As a result,<br /> idmap_kpti_install_ng_mappings panics the kernel when accessing<br /> __idmap_kpti_flag. Fix it by setting UXN on these PTEs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: bcd2000: Fix a UAF bug on the error path of probing<br /> <br /> When the driver fails in snd_card_register() at probe time, it will free<br /> the &amp;#39;bcd2k-&gt;midi_out_urb&amp;#39; before killing it, which may cause a UAF bug.<br /> <br /> The following log can reveal it:<br /> <br /> [ 50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]<br /> [ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0<br /> [ 50.729530] Call Trace:<br /> [ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]<br /> <br /> Fix this by adding usb_kill_urb() before usb_free_urb().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Don&amp;#39;t BUG if userspace injects an interrupt with GIF=0<br /> <br /> Don&amp;#39;t BUG/WARN on interrupt injection due to GIF being cleared,<br /> since it&amp;#39;s trivial for userspace to force the situation via<br /> KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct<br /> for KVM internally generated injections).<br /> <br /> kernel BUG at arch/x86/kvm/svm/svm.c:3386!<br /> invalid opcode: 0000 [#1] SMP<br /> CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd]<br /> Code: 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53<br /> RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006<br /> RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0<br /> RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000<br /> FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0<br /> Call Trace:<br /> <br /> inject_pending_event+0x2f7/0x4c0 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm]<br /> kvm_vcpu_ioctl+0x26d/0x650 [kvm]<br /> __x64_sys_ioctl+0x82/0xb0<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/xen: Initialize Xen timer only once<br /> <br /> Add a check for existing xen timers before initializing a new one.<br /> <br /> Currently kvm_xen_init_timer() is called on every<br /> KVM_XEN_VCPU_ATTR_TYPE_TIMER, which is causing the following ODEBUG<br /> crash when vcpu-&gt;arch.xen.timer is already set.<br /> <br /> ODEBUG: init active (active state 0)<br /> object type: hrtimer hint: xen_timer_callbac0<br /> RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:502<br /> Call Trace:<br /> __debug_object_init<br /> debug_hrtimer_init<br /> debug_init<br /> hrtimer_init<br /> kvm_xen_init_timer<br /> kvm_xen_vcpu_set_attr<br /> kvm_arch_vcpu_ioctl<br /> kvm_vcpu_ioctl<br /> vfs_ioctl

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak<br /> <br /> For some sev ioctl interfaces, input may be passed that is less than or<br /> equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP<br /> firmware returns. In this case, kmalloc will allocate memory that is the<br /> size of the input rather than the size of the data. Since PSP firmware<br /> doesn&amp;#39;t fully overwrite the buffer, the sev ioctl interfaces with the<br /> issue may return uninitialized slab memory.<br /> <br /> Currently, all of the ioctl interfaces in the ccp driver are safe, but<br /> to prevent future problems, change all ioctl interfaces that allocate<br /> memory with kmalloc to use kzalloc and memset the data buffer to zero<br /> in sev_ioctl_do_platform_status.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv:uprobe fix SR_SPIE set/clear handling<br /> <br /> In riscv the process of uprobe going to clear spie before exec<br /> the origin insn,and set spie after that.But When access the page<br /> which origin insn has been placed a page fault may happen and<br /> irq was disabled in arch_uprobe_pre_xol function,It cause a WARN<br /> as follows.<br /> There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.<br /> We can just remove it.<br /> <br /> [ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488<br /> [ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work<br /> [ 31.684929] preempt_count: 0, expected: 0<br /> [ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G<br /> [ 31.686542] Hardware name: riscv-virtio,qemu (DT)<br /> [ 31.686797] Call Trace:<br /> [ 31.687053] [] dump_backtrace+0x30/0x38<br /> [ 31.687699] [] show_stack+0x40/0x4c<br /> [ 31.688141] [] dump_stack_lvl+0x44/0x5c<br /> [ 31.688396] [] dump_stack+0x18/0x20<br /> [ 31.688653] [] __might_resched+0x114/0x122<br /> [ 31.688948] [] __might_sleep+0x50/0x7a<br /> [ 31.689435] [] down_read+0x30/0x130<br /> [ 31.689728] [] do_page_fault+0x166/x446<br /> [ 31.689997] [] ret_from_exception+0x0/0xc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT<br /> <br /> Treat the NX bit as valid when using NPT, as KVM will set the NX bit when<br /> the NX huge page mitigation is enabled (mindblowing) and trigger the WARN<br /> that fires on reserved SPTE bits being set.<br /> <br /> KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:<br /> Refuse to load kvm_amd if NX support is not available") for exactly this<br /> reason, but apparently it never occurred to anyone to actually test NPT<br /> with the mitigation enabled.<br /> <br /> ------------[ cut here ]------------<br /> spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000<br /> WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm]<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022<br /> RIP: 0010:make_spte+0x327/0x340 [kvm]<br /> Call Trace:<br /> <br /> tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm]<br /> kvm_tdp_mmu_map+0x343/0x3b0 [kvm]<br /> direct_page_fault+0x1ae/0x2a0 [kvm]<br /> kvm_tdp_page_fault+0x7d/0x90 [kvm]<br /> kvm_mmu_page_fault+0xfb/0x2e0 [kvm]<br /> npf_interception+0x55/0x90 [kvm_amd]<br /> svm_invoke_exit_handler+0x31/0xf0 [kvm_amd]<br /> svm_handle_exit+0xf6/0x1d0 [kvm_amd]<br /> vcpu_enter_guest+0xb6d/0xee0 [kvm]<br /> ? kvm_pmu_trigger_event+0x6d/0x230 [kvm]<br /> vcpu_run+0x65/0x2c0 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm]<br /> kvm_vcpu_ioctl+0x551/0x610 [kvm]<br /> __se_sys_ioctl+0x77/0xc0<br /> __x64_sys_ioctl+0x1d/0x20<br /> do_syscall_64+0x44/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK<br /> <br /> When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,<br /> cpu_max_bits_warn() generates a runtime warning similar as below while<br /> we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)<br /> instead of NR_CPUS to iterate CPUs.<br /> <br /> [ 3.052463] ------------[ cut here ]------------<br /> [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0<br /> [ 3.070072] Modules linked in: efivarfs autofs4<br /> [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052<br /> [ 3.084034] Hardware name: Loongson Loongson-3A5000-7A1000-1w-V0.1-CRB/Loongson-LS3A5000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27<br /> [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000<br /> [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430<br /> [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff<br /> [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890<br /> [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa<br /> [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000<br /> [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000<br /> [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000<br /> [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286<br /> [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c<br /> [ 3.195868] ...<br /> [ 3.199917] Call Trace:<br /> [ 3.203941] [] show_stack+0x38/0x14c<br /> [ 3.210666] [] dump_stack_lvl+0x60/0x88<br /> [ 3.217625] [] __warn+0xd0/0x100<br /> [ 3.223958] [] warn_slowpath_fmt+0x7c/0xcc<br /> [ 3.231150] [] show_cpuinfo+0x5e8/0x5f0<br /> [ 3.238080] [] seq_read_iter+0x354/0x4b4<br /> [ 3.245098] [] new_sync_read+0x17c/0x1c4<br /> [ 3.252114] [] vfs_read+0x138/0x1d0<br /> [ 3.258694] [] ksys_read+0x70/0x100<br /> [ 3.265265] [] do_syscall+0x7c/0x94<br /> [ 3.271820] [] handle_syscall+0xc4/0x160<br /> [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---