Vulnerabilities

A missing length check in `ogs_pfcp_dev_add` function from PFCP library, used by both smf and upf in open5gs 2.7.2 and earlier, allows a local attacker to cause a Buffer Overflow by changing the `session.dev` field with a value with length greater than 32.

IBM Sterling B2B Integrator and IBM Sterling File Gateway 6.0.0.0 through 6.1.2.6 and 6.2.0.0 through 6.2.0.4 is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

Improper Input Validation vulnerability in Profisee on Windows (filesystem modules) allows Path Traversal after authentication to the Profisee system.This issue affects Profisee: from 2020R1 before 2024R2.

Real Estate Management 1.0 is vulnerable to Cross Site Scripting (XSS) in /store/index.php.

SQL Injection vulnerability in pbootCMS v.3.2.5 and v.3.2.10 allows a remote attacker to obtain sensitive information via a crafted GET request

An issue in EfroTech Time Trax v.1.0 allows a remote attacker to execute arbitrary code via the file attachment function in the leave request form

A cross-site scripting (XSS) vulnerability in miniTCG v1.3.1 beta allows attackers to execute abritrary web scripts or HTML via injecting a crafted payload into the id parameter at /members/edit.php.

D-Link DPH-400S/SE VoIP Phone v1.01 contains hardcoded provisioning variables, including PROVIS_USER_PASSWORD, which may expose sensitive user credentials. An attacker with access to the firmware image can extract these credentials using static analysis tools such as strings or xxd, potentially leading to unauthorized access to device functions or user accounts. This vulnerability exists due to insecure storage of sensitive information in the firmware binary.

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---