Vulnerabilities

Weak Password Requirements vulnerability in Mitsubishi Electric Corporation photovoltaic system monitor “EcoGuideTAB” PV-DR004J all versions and PV-DR004JA all versions allows an attacker within the Wi-Fi communication range between the units of the product (measurement unit and display unit) to derive the password from the SSID. However, the product is not affected by this vulnerability when it remains unused for a certain period of time (default: 5 minutes) and enters the power-saving mode with the display unit's LCD screen turned off. The affected products discontinued in 2015, support ended in 2020.

Use of Hard-coded Credentials vulnerability in Mitsubishi Electric Corporation photovoltaic system monitor “EcoGuideTAB” PV-DR004J all versions and PV-DR004JA all versions allows an attacker within the Wi-Fi communication range between the units of the product (measurement unit and display unit) to disclose information such as generated power and electricity sold back to the grid stored in the product, tamper with or destroy stored or configured information in the product, or cause a Denial-of-Service (DoS) condition on the product, by using hardcoded user ID and password common to the product series obtained by exploiting CVE-2025-5022. However, the product is not affected by this vulnerability when it remains unused for a certain period of time (default: 5 minutes) and enters the power-saving mode with the display unit's LCD screen turned off. The affected products discontinued in 2015, support ended in 2020.

An issue has been discovered in GitLab EE affecting all versions from 18.0 before 18.0.4 and 18.1 before 18.1.2 that could have allowed authenticated maintainers to bypass group-level user invitation restrictions by sending crafted API requests.

An issue has been discovered in GitLab CE/EE affecting all versions from 17.11 before 17.11.6, 18.0 before 18.0.4, and 18.1 before 18.1.2 that, under certain conditions, could have allowed a successful attacker to execute actions on behalf of users by injecting malicious content.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> software node: Correct a OOB check in software_node_get_reference_args()<br /> <br /> software_node_get_reference_args() wants to get @index-th element, so<br /> the property value requires at least &amp;#39;(index + 1) * sizeof(*ref)&amp;#39; bytes<br /> but that can not be guaranteed by current OOB check, and may cause OOB<br /> for malformed property.<br /> <br /> Fix by using as OOB check &amp;#39;((index + 1) * sizeof(*ref) &gt; prop-&gt;length)&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: drop fragments with multicast or broadcast RA<br /> <br /> IEEE 802.11 fragmentation can only be applied to unicast frames.<br /> Therefore, drop fragments with multicast or broadcast RA. This patch<br /> addresses vulnerabilities such as CVE-2020-26145.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: fix acpi parse and parseext cache leaks<br /> <br /> ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5<br /> <br /> I&amp;#39;m Seunghun Han, and I work for National Security Research Institute of<br /> South Korea.<br /> <br /> I have been doing a research on ACPI and found an ACPI cache leak in ACPI<br /> early abort cases.<br /> <br /> Boot log of ACPI cache leak is as follows:<br /> [ 0.352414] ACPI: Added _OSI(Module Device)<br /> [ 0.353182] ACPI: Added _OSI(Processor Device)<br /> [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)<br /> [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)<br /> [ 0.356028] ACPI: Unable to start the ACPI Interpreter<br /> [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)<br /> [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects<br /> [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W<br /> 4.12.0-rc4-next-20170608+ #10<br /> [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS<br /> virtual_box 12/01/2006<br /> [ 0.361873] Call Trace:<br /> [ 0.362243] ? dump_stack+0x5c/0x81<br /> [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0<br /> [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.363296] ? acpi_os_delete_cache+0xa/0x10<br /> [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b<br /> [ 0.364000] ? acpi_terminate+0xa/0x14<br /> [ 0.364000] ? acpi_init+0x2af/0x34f<br /> [ 0.364000] ? __class_create+0x4c/0x80<br /> [ 0.364000] ? video_setup+0x7f/0x7f<br /> [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.364000] ? do_one_initcall+0x4e/0x1a0<br /> [ 0.364000] ? kernel_init_freeable+0x189/0x20a<br /> [ 0.364000] ? rest_init+0xc0/0xc0<br /> [ 0.364000] ? kernel_init+0xa/0x100<br /> [ 0.364000] ? ret_from_fork+0x25/0x30<br /> <br /> I analyzed this memory leak in detail. I found that “Acpi-State” cache and<br /> “Acpi-Parse” cache were merged because the size of cache objects was same<br /> slab cache size.<br /> <br /> I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked<br /> using SLAB_NEVER_MERGE flag in kmem_cache_create() function.<br /> <br /> Real ACPI cache leak point is as follows:<br /> [ 0.360101] ACPI: Added _OSI(Module Device)<br /> [ 0.360101] ACPI: Added _OSI(Processor Device)<br /> [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)<br /> [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)<br /> [ 0.364016] ACPI: Unable to start the ACPI Interpreter<br /> [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)<br /> [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects<br /> [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W<br /> 4.12.0-rc4-next-20170608+ #8<br /> [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS<br /> virtual_box 12/01/2006<br /> [ 0.372000] Call Trace:<br /> [ 0.372000] ? dump_stack+0x5c/0x81<br /> [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0<br /> [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.372000] ? acpi_os_delete_cache+0xa/0x10<br /> [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b<br /> [ 0.372000] ? acpi_terminate+0xa/0x14<br /> [ 0.372000] ? acpi_init+0x2af/0x34f<br /> [ 0.372000] ? __class_create+0x4c/0x80<br /> [ 0.372000] ? video_setup+0x7f/0x7f<br /> [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.372000] ? do_one_initcall+0x4e/0x1a0<br /> [ 0.372000] ? kernel_init_freeable+0x189/0x20a<br /> [ 0.372000] ? rest_init+0xc0/0xc0<br /> [ 0.372000] ? kernel_init+0xa/0x100<br /> [ 0.372000] ? ret_from_fork+0x25/0x30<br /> [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects<br /> [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W<br /> 4.12.0-rc4-next-20170608+ #8<br /> [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS<br /> virtual_box 12/01/2006<br /> [ 0.392000] Call Trace:<br /> [ 0.392000] ? dump_stack+0x5c/0x81<br /> [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0<br /> [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.392000] ? acpi_os_delete_cache+0xa/0x10<br /> [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b<br /> [ 0.392000] ? acpi_terminate+0xa/0x14<br /> [ 0.392000] ? acpi_init+0x2af/0x3<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: fix acpi operand cache leak in dswstate.c<br /> <br /> ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732<br /> <br /> I found an ACPI cache leak in ACPI early termination and boot continuing case.<br /> <br /> When early termination occurs due to malicious ACPI table, Linux kernel<br /> terminates ACPI function and continues to boot process. While kernel terminates<br /> ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.<br /> <br /> Boot log of ACPI operand cache leak is as follows:<br /> &gt;[ 0.585957] ACPI: Added _OSI(Module Device)<br /> &gt;[ 0.587218] ACPI: Added _OSI(Processor Device)<br /> &gt;[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)<br /> &gt;[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)<br /> &gt;[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)<br /> &gt;[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)<br /> &gt;[ 0.597858] ACPI: Unable to start the ACPI Interpreter<br /> &gt;[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)<br /> &gt;[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects<br /> &gt;[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26<br /> &gt;[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006<br /> &gt;[ 0.609177] Call Trace:<br /> &gt;[ 0.610063] ? dump_stack+0x5c/0x81<br /> &gt;[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0<br /> &gt;[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27<br /> &gt;[ 0.613906] ? acpi_os_delete_cache+0xa/0x10<br /> &gt;[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b<br /> &gt;[ 0.619293] ? acpi_terminate+0xa/0x14<br /> &gt;[ 0.620394] ? acpi_init+0x2af/0x34f<br /> &gt;[ 0.621616] ? __class_create+0x4c/0x80<br /> &gt;[ 0.623412] ? video_setup+0x7f/0x7f<br /> &gt;[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27<br /> &gt;[ 0.625861] ? do_one_initcall+0x4e/0x1a0<br /> &gt;[ 0.627513] ? kernel_init_freeable+0x19e/0x21f<br /> &gt;[ 0.628972] ? rest_init+0x80/0x80<br /> &gt;[ 0.630043] ? kernel_init+0xa/0x100<br /> &gt;[ 0.631084] ? ret_from_fork+0x25/0x30<br /> &gt;[ 0.633343] vgaarb: loaded<br /> &gt;[ 0.635036] EDAC MC: Ver: 3.0.0<br /> &gt;[ 0.638601] PCI: Probing PCI hardware<br /> &gt;[ 0.639833] PCI host bridge to bus 0000:00<br /> &gt;[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]<br /> &gt; ... Continue to boot and log is omitted ...<br /> <br /> I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_<br /> delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()<br /> function uses walk_state-&gt;operand_index for start position of the top, but<br /> acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.<br /> Therefore, this causes acpi operand memory leak.<br /> <br /> This cache leak causes a security threat because an old kernel (

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix UAF when lookup kallsym after ftrace disabled<br /> <br /> The following issue happens with a buggy module:<br /> <br /> BUG: unable to handle page fault for address: ffffffffc05d0218<br /> PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0<br /> Oops: Oops: 0000 [#1] SMP KASAN PTI<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> RIP: 0010:sized_strscpy+0x81/0x2f0<br /> RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000<br /> RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d<br /> RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68<br /> R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038<br /> R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff<br /> FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ftrace_mod_get_kallsym+0x1ac/0x590<br /> update_iter_mod+0x239/0x5b0<br /> s_next+0x5b/0xa0<br /> seq_read_iter+0x8c9/0x1070<br /> seq_read+0x249/0x3b0<br /> proc_reg_read+0x1b0/0x280<br /> vfs_read+0x17f/0x920<br /> ksys_read+0xf3/0x1c0<br /> do_syscall_64+0x5f/0x2e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The above issue may happen as follows:<br /> (1) Add kprobe tracepoint;<br /> (2) insmod test.ko;<br /> (3) Module triggers ftrace disabled;<br /> (4) rmmod test.ko;<br /> (5) cat /proc/kallsyms; --&gt; Will trigger UAF as test.ko already removed;<br /> ftrace_mod_get_kallsym()<br /> ...<br /> strscpy(module_name, mod_map-&gt;mod-&gt;name, MODULE_NAME_LEN);<br /> ...<br /> <br /> The problem is when a module triggers an issue with ftrace and<br /> sets ftrace_disable. The ftrace_disable is set when an anomaly is<br /> discovered and to prevent any more damage, ftrace stops all text<br /> modification. The issue that happened was that the ftrace_disable stops<br /> more than just the text modification.<br /> <br /> When a module is loaded, its init functions can also be traced. Because<br /> kallsyms deletes the init functions after a module has loaded, ftrace<br /> saves them when the module is loaded and function tracing is enabled. This<br /> allows the output of the function trace to show the init function names<br /> instead of just their raw memory addresses.<br /> <br /> When a module is removed, ftrace_release_mod() is called, and if<br /> ftrace_disable is set, it just returns without doing anything more. The<br /> problem here is that it leaves the mod_list still around and if kallsyms<br /> is called, it will call into this code and access the module memory that<br /> has already been freed as it will return:<br /> <br /> strscpy(module_name, mod_map-&gt;mod-&gt;name, MODULE_NAME_LEN);<br /> <br /> Where the "mod" no longer exists and triggers a UAF bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on ino and xnid<br /> <br /> syzbot reported a f2fs bug as below:<br /> <br /> INFO: task syz-executor140:5308 blocked for more than 143 seconds.<br /> Not tainted 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz-executor140 state:D stack:24016 pid:5308 tgid:5308 ppid:5306 task_flags:0x400140 flags:0x00000006<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5378 [inline]<br /> __schedule+0x190e/0x4c90 kernel/sched/core.c:6765<br /> __schedule_loop kernel/sched/core.c:6842 [inline]<br /> schedule+0x14b/0x320 kernel/sched/core.c:6857<br /> io_schedule+0x8d/0x110 kernel/sched/core.c:7690<br /> folio_wait_bit_common+0x839/0xee0 mm/filemap.c:1317<br /> __folio_lock mm/filemap.c:1664 [inline]<br /> folio_lock include/linux/pagemap.h:1163 [inline]<br /> __filemap_get_folio+0x147/0xb40 mm/filemap.c:1917<br /> pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87<br /> find_get_page_flags include/linux/pagemap.h:842 [inline]<br /> f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776<br /> __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463<br /> read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306<br /> lookup_all_xattrs fs/f2fs/xattr.c:355 [inline]<br /> f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533<br /> __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179<br /> f2fs_acl_create fs/f2fs/acl.c:375 [inline]<br /> f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418<br /> f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539<br /> f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666<br /> f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765<br /> f2fs_do_add_link+0x28c/0x3a0 fs/f2fs/dir.c:808<br /> f2fs_add_link fs/f2fs/f2fs.h:3616 [inline]<br /> f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766<br /> vfs_mknod+0x36d/0x3b0 fs/namei.c:4191<br /> unix_bind_bsd net/unix/af_unix.c:1286 [inline]<br /> unix_bind+0x563/0xe30 net/unix/af_unix.c:1379<br /> __sys_bind_socket net/socket.c:1817 [inline]<br /> __sys_bind+0x1e4/0x290 net/socket.c:1848<br /> __do_sys_bind net/socket.c:1853 [inline]<br /> __se_sys_bind net/socket.c:1851 [inline]<br /> __x64_sys_bind+0x7a/0x90 net/socket.c:1851<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Let&amp;#39;s dump and check metadata of corrupted inode, it shows its xattr_nid<br /> is the same to its i_ino.<br /> <br /> dump.f2fs -i 3 chaseyu.img.raw<br /> i_xattr_nid [0x 3 : 3]<br /> <br /> So that, during mknod in the corrupted directory, it tries to get and<br /> lock inode page twice, result in deadlock.<br /> <br /> - f2fs_mknod<br /> - f2fs_add_inline_entry<br /> - f2fs_get_inode_page --- lock dir&amp;#39;s inode page<br /> - f2fs_init_acl<br /> - f2fs_acl_create(dir,..)<br /> - __f2fs_get_acl<br /> - f2fs_getxattr<br /> - lookup_all_xattrs<br /> - __get_node_page --- try to lock dir&amp;#39;s inode page<br /> <br /> In order to fix this, let&amp;#39;s add sanity check on ino and xnid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()<br /> <br /> Robert Morris reported:<br /> <br /> |If a malicious USB device pretends to be an Intersil p54 wifi<br /> |interface and generates an eeprom_readback message with a large<br /> |eeprom-&gt;v1.len, p54_rx_eeprom_readback() will copy data from the<br /> |message beyond the end of priv-&gt;eeprom.<br /> |<br /> |static void p54_rx_eeprom_readback(struct p54_common *priv,<br /> | struct sk_buff *skb)<br /> |{<br /> | struct p54_hdr *hdr = (struct p54_hdr *) skb-&gt;data;<br /> | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-&gt;data;<br /> |<br /> | if (priv-&gt;fw_var &gt;= 0x509) {<br /> | memcpy(priv-&gt;eeprom, eeprom-&gt;v2.data,<br /> | le16_to_cpu(eeprom-&gt;v2.len));<br /> | } else {<br /> | memcpy(priv-&gt;eeprom, eeprom-&gt;v1.data,<br /> | le16_to_cpu(eeprom-&gt;v1.len));<br /> | }<br /> | [...]<br /> <br /> The eeprom-&gt;v{1,2}.len is set by the driver in p54_download_eeprom().<br /> The device is supposed to provide the same length back to the driver.<br /> But yes, it&amp;#39;s possible (like shown in the report) to alter the value<br /> to something that causes a crash/panic due to overrun.<br /> <br /> This patch addresses the issue by adding the size to the common device<br /> context, so p54_rx_eeprom_readback no longer relies on possibly tampered<br /> values... That said, it also checks if the "firmware" altered the value<br /> and no longer copies them.<br /> <br /> The one, small saving grace is: Before the driver tries to read the eeprom,<br /> it needs to upload &gt;a

An issue has been discovered in GitLab EE affecting all versions from 13.3 before 17.11.6, 18.0 before 18.0.4, and 18.1 before 18.1.2 that could have allowed authenticated project owners to bypass group-level forking restrictions by manipulating API requests.