Vulnerabilities

The specific flaw exists within the Bluetooth stack developed by Alps Alpine of the Infotainment ECU manufactured by Bosch. The issue results from the lack of proper boundary validation of user-supplied data, which can result in a stack-based buffer overflow when receiving a specific packet on the established upper layer L2CAP channel. An attacker can leverage this vulnerability to obtain remote code execution on the Infotainment ECU with root privileges.<br /> <br /> <br /> <br /> First identified on Nissan Leaf ZE1 manufactured in 2020.

There is a misconfiguration vulnerability inside the Infotainment ECU manufactured by BOSCH. The vulnerability happens during the startup phase of a specific systemd service, and as a result, the following developer features will be activated: the disabled firewall and the launched SSH server.<br /> <br /> <br /> <br /> First identified on Nissan Leaf ZE1 manufactured in 2020.

The RF communication protocol in the Micca KE700 car alarm system does not encrypt its data frames. An attacker with a radio interception tool (e.g., SDR) can capture the random number and counters transmitted in cleartext, which is sensitive information required for authentication.

The specific flaw exists within the Bluetooth stack developed by Alps Alpine of the Infotainment ECU manufactured by Bosch. The issue results from the lack of proper boundary validation of user-supplied data, which can result in a stack-based buffer overflow when receiving a specific packet on the established upper layer L2CAP channel. An attacker can leverage this vulnerability to obtain remote code execution on the Infotainment ECU with root privileges.<br /> <br /> <br /> <br /> First identified on Nissan Leaf ZE1 manufactured in 2020.

The Infotainment ECU manufactured by Bosch uses a RH850 module for CAN communication. RH850 is connected to infotainment over the INC interface through a custom protocol. There is a vulnerability during processing requests of this protocol on the V850 side which allows an attacker with code execution on the infotainment main SoC to perform code execution on the RH850 module and subsequently send arbitrary CAN messages over the connected CAN bus.<br /> <br /> <br /> <br /> First identified on Nissan Leaf ZE1 manufactured in 2020.

The Ecwid by Lightspeed Ecommerce Shopping Cart plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 7.0.7. This is due to a missing capability check in the &amp;#39;save_custom_user_profile_fields&amp;#39; function. This makes it possible for authenticated attackers, with minimal permissions such as a subscriber, to supply the &amp;#39;ec_store_admin_access&amp;#39; parameter during a profile update and gain store manager access to the site.

The Element Pack Addons for Elementor plugin for WordPress is vulnerable to arbitrary file reads in all versions up to, and including, 8.3.17 via the SVG widget and a lack of sufficient file validation in the &amp;#39;render_svg&amp;#39; function. This makes it possible for authenticated attackers, with contributor-level access and above, to read the contents of arbitrary files on the server, which can contain sensitive information.

The Spam protection, Anti-Spam, FireWall by CleanTalk plugin for WordPress is vulnerable to unauthorized Arbitrary Plugin Installation due to an authorization bypass via reverse DNS (PTR record) spoofing on the &amp;#39;checkWithoutToken&amp;#39; function in all versions up to, and including, 6.71. This makes it possible for unauthenticated attackers to install and activate arbitrary plugins which can be leveraged to achieve remote code execution if another vulnerable plugin is installed and activated. Note: This is only exploitable on sites with an invalid API key.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer<br /> <br /> The curr_xfer field is read by the IRQ handler without holding the lock<br /> to check if a transfer is in progress. When clearing curr_xfer in the<br /> combined sequence transfer loop, protect it with the spinlock to prevent<br /> a race with the interrupt handler.<br /> <br /> Protect the curr_xfer clearing at the exit path of<br /> tegra_qspi_combined_seq_xfer() with the spinlock to prevent a race<br /> with the interrupt handler that reads this field.<br /> <br /> Without this protection, the IRQ handler could read a partially updated<br /> curr_xfer value, leading to NULL pointer dereference or use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cpsw_new: Execute ndo_set_rx_mode callback in a work queue<br /> <br /> Commit 1767bb2d47b7 ("ipv6: mcast: Don&amp;#39;t hold RTNL for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.") removed the RTNL lock for<br /> IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this<br /> change triggered the following call trace on my BeagleBone Black board:<br /> WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/496<br /> RTNL: assertion failed at net/8021q/vlan_core.c (236)<br /> Modules linked in:<br /> CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT<br /> Hardware name: Generic AM33XX (Flattened Device Tree)<br /> Call trace:<br /> unwind_backtrace from show_stack+0x28/0x2c<br /> show_stack from dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl from __warn+0xb8/0x11c<br /> __warn from warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt from vlan_for_each+0x120/0x124<br /> vlan_for_each from cpsw_add_mc_addr+0x54/0xd8<br /> cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88<br /> __dev_mc_add from igmp6_group_added+0x84/0xec<br /> igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt from __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt from ret_fast_syscall+0x0/0x5<br /> <br /> This trace occurs because vlan_for_each() is called within<br /> cpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.<br /> Since modifying vlan_for_each() to operate without the RTNL lock is not<br /> straightforward, and because ndo_set_rx_mode() is invoked both with and<br /> without the RTNL lock across different code paths, simply adding<br /> rtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.<br /> <br /> To resolve this issue, we opt to execute the actual processing within<br /> a work queue, following the approach used by the icssg-prueth driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_u32: use skb_header_pointer_careful()<br /> <br /> skb_header_pointer() does not fully validate negative @offset values.<br /> <br /> Use skb_header_pointer_careful() instead.<br /> <br /> GangMin Kim provided a report and a repro fooling u32_classify():<br /> <br /> BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0<br /> net/sched/cls_u32.c:221

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: fix memory leak in smb2_open_file()<br /> <br /> Reproducer:<br /> <br /> 1. server: directories are exported read-only<br /> 2. client: mount -t cifs //${server_ip}/export /mnt<br /> 3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct<br /> 4. client: umount /mnt<br /> 5. client: sleep 1<br /> 6. client: modprobe -r cifs<br /> <br /> The error message is as follows:<br /> <br /> =============================================================================<br /> BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown()<br /> -----------------------------------------------------------------------------<br /> <br /> Object 0x00000000d47521be @offset=14336<br /> ...<br /> WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577<br /> ...<br /> Call Trace:<br /> <br /> kmem_cache_destroy+0x94/0x190<br /> cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> cleanup_module+0x4e/0x540 [cifs]<br /> __se_sys_delete_module+0x278/0x400<br /> __x64_sys_delete_module+0x5f/0x70<br /> x64_sys_call+0x2299/0x2ff0<br /> do_syscall_64+0x89/0x350<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577