Vulnerabilities

idccms v1.35 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/memberOnline_deal.php?mudi=del&dataType=&dataID=6

idccms v1.35 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/softBak_deal.php?mudi=backup

idccms v1.35 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/softBak_deal.php?mudi=del&dataID=2

idccms v1.35 was discovered to contain a Cross-Site Request Forgery (CSRF) vulnerability via /admin/serverFile_deal.php?mudi=upFileDel&dataID=3

Insecure handling of POST header parameter body included in requests being sent to an instance of the open-source project Phoniebox allows an attacker to create a website, which – when visited by a user – will send malicious requests to multiple hosts on the local network. If such a request reaches the server, it will cause a shell command execution.<br /> <br /> <br /> This issue affects Phoniebox in all releases through 2.7. Newer 2.x releases were not tested, but they might also be vulnerable. <br /> Phoniebox in version 3.0 and higher are not affected.

Insecure handling of GET header parameter file included in requests being sent to an instance of the open-source project Phoniebox allows an attacker to create a website, which – when visited by a user – will send malicious requests to multiple hosts on the local network. If such a request reaches the server, it will cause one of the following (depending on the chosen payload): shell command execution, reflected XSS or cross-site request forgery.<br /> <br /> <br /> This issue affects Phoniebox in all releases through 2.7. Newer 2.x releases were not tested, but they might also be vulnerable. <br /> Phoniebox in version 3.0 and higher are not affected.

The SmartCrawl WordPress SEO checker, SEO analyzer, SEO optimizer plugin for WordPress is vulnerable to Full Path Disclosure in all versions up to, and including, 3.10.8. This is due the plugin utilizing mobiledetect without preventing direct access to the files. This makes it possible for unauthenticated attackers to retrieve the full path of the web application, which can be used to aid other attacks. The information displayed is not useful on its own, and requires another vulnerability to be present for damage to an affected website.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY<br /> <br /> When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes<br /> to bug_table entries, and as a result the last entry in a bug table will<br /> be ignored, potentially leading to an unexpected panic(). All prior<br /> entries in the table will be handled correctly.<br /> <br /> The arm64 ABI requires that struct fields of up to 8 bytes are<br /> naturally-aligned, with padding added within a struct such that struct<br /> are suitably aligned within arrays.<br /> <br /> When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:<br /> <br /> struct bug_entry {<br /> signed int bug_addr_disp; // 4 bytes<br /> signed int file_disp; // 4 bytes<br /> unsigned short line; // 2 bytes<br /> unsigned short flags; // 2 bytes<br /> }<br /> <br /> ... with 12 bytes total, requiring 4-byte alignment.<br /> <br /> When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:<br /> <br /> struct bug_entry {<br /> signed int bug_addr_disp; // 4 bytes<br /> unsigned short flags; // 2 bytes<br /> // 2 bytes<br /> }<br /> <br /> ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing<br /> padding, requiring 4-byte alginment.<br /> <br /> When we create a bug_entry in assembly, we align the start of the entry<br /> to 4 bytes, which implicitly handles padding for any prior entries.<br /> However, we do not align the end of the entry, and so when<br /> CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding<br /> bytes.<br /> <br /> For the main kernel image this is not a problem as find_bug() doesn&amp;#39;t<br /> depend on the trailing padding bytes when searching for entries:<br /> <br /> for (bug = __start___bug_table; bug num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);<br /> <br /> ... and as the last bug_entry lacks the necessary padding bytes, this entry<br /> will not be counted, e.g. in the case of a single entry:<br /> <br /> sechdrs[i].sh_size == 6<br /> sizeof(struct bug_entry) == 8;<br /> <br /> sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;<br /> <br /> Consequently module_find_bug() will miss the last bug_entry when it does:<br /> <br /> for (i = 0; i num_bugs; ++i, ++bug)<br /> if (bugaddr == bug_addr(bug))<br /> goto out;<br /> <br /> ... which can lead to a kenrel panic due to an unhandled bug.<br /> <br /> This can be demonstrated with the following module:<br /> <br /> static int __init buginit(void)<br /> {<br /> WARN(1, "hello\n");<br /> return 0;<br /> }<br /> <br /> static void __exit bugexit(void)<br /> {<br /> }<br /> <br /> module_init(buginit);<br /> module_exit(bugexit);<br /> MODULE_LICENSE("GPL");<br /> <br /> ... which will trigger a kernel panic when loaded:<br /> <br /> ------------[ cut here ]------------<br /> hello<br /> Unexpected kernel BRK exception at EL1<br /> Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP<br /> Modules linked in: hello(O+)<br /> CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : buginit+0x18/0x1000 [hello]<br /> lr : buginit+0x18/0x1000 [hello]<br /> sp : ffff800080533ae0<br /> x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000<br /> x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58<br /> x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0<br /> x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006<br /> x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720<br /> x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312<br /> x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8<br /> x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000<br /> x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0<br /> Call trace:<br /> buginit+0x18/0x1000 [hello]<br /> do_one_initcall+0x80/0x1c8<br /> do_init_module+0x60/0x218<br /> load_module+0x1ba4/0x1d70<br /> __do_sys_init_module+0x198/0x1d0<br /> __arm64_sys_init_module+0x1c/0x28<br /> invoke_syscall+0x48/0x114<br /> el0_svc<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: sr: fix memleak in seg6_hmac_init_algo<br /> <br /> seg6_hmac_init_algo returns without cleaning up the previous allocations<br /> if one fails, so it&amp;#39;s going to leak all that memory and the crypto tfms.<br /> <br /> Update seg6_hmac_exit to only free the memory when allocated, so we can<br /> reuse the code directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: sr: fix missing sk_buff release in seg6_input_core<br /> <br /> The seg6_input() function is responsible for adding the SRH into a<br /> packet, delegating the operation to the seg6_input_core(). This function<br /> uses the skb_cow_head() to ensure that there is sufficient headroom in<br /> the sk_buff for accommodating the link-layer header.<br /> In the event that the skb_cow_header() function fails, the<br /> seg6_input_core() catches the error but it does not release the sk_buff,<br /> which will result in a memory leak.<br /> <br /> This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due<br /> to headroom too small after SRH push") and persists even after commit<br /> 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),<br /> where the entire seg6_input() code was refactored to deal with netfilter<br /> hooks.<br /> <br /> The proposed patch addresses the identified memory leak by requiring the<br /> seg6_input_core() function to release the sk_buff in the event that<br /> skb_cow_head() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: cs35l56: Fix lifetime of cs_dsp instance<br /> <br /> The cs_dsp instance is initialized in the driver probe() so it<br /> should be freed in the driver remove(). Also fix a missing call<br /> to cs_dsp_remove() in the error path of cs35l56_hda_common_probe().<br /> <br /> The call to cs_dsp_remove() was being done in the component unbind<br /> callback cs35l56_hda_unbind(). This meant that if the driver was<br /> unbound and then re-bound it would be using an uninitialized cs_dsp<br /> instance.<br /> <br /> It is best to initialize the cs_dsp instance in probe() so that it<br /> can return an error if it fails. The component binding API doesn&amp;#39;t<br /> have any error handling so there&amp;#39;s no way to handle a failure if<br /> cs_dsp was initialized in the bind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mtk-cmdq: Fix pm_runtime_get_sync() warning in mbox shutdown<br /> <br /> The return value of pm_runtime_get_sync() in cmdq_mbox_shutdown()<br /> will return 1 when pm runtime state is active, and we don&amp;#39;t want to<br /> get the warning message in this case.<br /> <br /> So we change the return value