Vulnerabilities

A heap buffer overflow in the image processing binary of the MIB3 infotainment unit allows an attacker to execute arbitrary code on it.<br /> The vulnerability was originally discovered in Skoda Superb III car with MIB3 infotainment unit OEM part number 3V0035820. The list of affected MIB3 OEM part numbers is provided in the referenced resources.

A command injection in the networking service of the MIB3 infotainment allows an attacker already presenting in the system to escalate privileges and obtain administrative access to the system.<br /> The vulnerability was originally discovered in Skoda Superb III car with MIB3 infotainment unit OEM part number 3V0035820. The list of affected MIB3 OEM part numbers is provided in the referenced resources.

There is no memory isolation between CPU cores of the MIB3 infotainment. This fact allows an attacker with access to the main operating system to compromise the CPU core responsible for CAN message processing.<br /> The vulnerability was originally discovered in Skoda Superb III car with MIB3 infotainment unit OEM part number 3V0035820. The list of affected MIB3 OEM part numbers is provided in the referenced resources.

A specific flaw exists within the Bluetooth stack of the MIB3 infotainment. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow when receiving non-fragmented HCI packets on a channel.<br /> The vulnerability was originally discovered in Skoda Superb III car with MIB3 infotainment unit OEM part number 3V0035820. The list of affected MIB3 OEM part numbers is provided in the referenced resources.

An integer underflow in the image processing binary of the MIB3 infotainment unit allows an attacker with local access to the vehicle to cause denial-of-service of the infotainment system.<br /> The vulnerability was originally discovered in Skoda Superb III car with MIB3 infotainment unit OEM part number 3V0035820. The list of affected MIB3 OEM part numbers is provided in the referenced resources.

IBM Informix Dynamic Server 12.10,14.10, and15.0 could allow a remote attacker to cause a denial of service due to an integer underflow when processing packets.

A vulnerability, which was classified as problematic, has been found in HDF5 1.14.6. This issue affects the function H5C__load_entry of the file /src/H5Centry.c. The manipulation leads to resource consumption. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used.

The MicroPayments – Fans Paysite: Paid Creator Subscriptions, Digital Assets, Wallet plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 3.2.0. This is due to missing or incorrect nonce validation on the adminOptions() function. This makes it possible for unauthenticated attackers to reset the plugin&amp;#39;s settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

A vulnerability classified as problematic was found in HDF5 1.14.6. This vulnerability affects the function H5O__fsinfo_encode of the file /src/H5Ofsinfo.c. The manipulation leads to heap-based buffer overflow. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ch9200: fix uninitialised access during mii_nway_restart<br /> <br /> In mii_nway_restart() the code attempts to call<br /> mii-&gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()<br /> utilises a local buffer called "buff", which is initialised<br /> with control_read(). However "buff" is conditionally<br /> initialised inside control_read():<br /> <br /> if (err == size) {<br /> memcpy(data, buf, size);<br /> }<br /> <br /> If the condition of "err == size" is not met, then<br /> "buff" remains uninitialised. Once this happens the<br /> uninitialised "buff" is accessed and returned during<br /> ch9200_mdio_read():<br /> <br /> return (buff[0] | buff[1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race<br /> <br /> huge_pmd_unshare() drops a reference on a page table that may have<br /> previously been shared across processes, potentially turning it into a<br /> normal page table used in another process in which unrelated VMAs can<br /> afterwards be installed.<br /> <br /> If this happens in the middle of a concurrent gup_fast(), gup_fast() could<br /> end up walking the page tables of another process. While I don&amp;#39;t see any<br /> way in which that immediately leads to kernel memory corruption, it is<br /> really weird and unexpected.<br /> <br /> Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),<br /> just like we do in khugepaged when removing page tables for a THP<br /> collapse.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: unshare page tables during VMA split, not before<br /> <br /> Currently, __split_vma() triggers hugetlb page table unsharing through<br /> vm_ops-&gt;may_split(). This happens before the VMA lock and rmap locks are<br /> taken - which is too early, it allows racing VMA-locked page faults in our<br /> process and racing rmap walks from other processes to cause page tables to<br /> be shared again before we actually perform the split.<br /> <br /> Fix it by explicitly calling into the hugetlb unshare logic from<br /> __split_vma() in the same place where THP splitting also happens. At that<br /> point, both the VMA and the rmap(s) are write-locked.<br /> <br /> An annoying detail is that we can now call into the helper<br /> hugetlb_unshare_pmds() from two different locking contexts:<br /> <br /> 1. from hugetlb_split(), holding:<br /> - mmap lock (exclusively)<br /> - VMA lock<br /> - file rmap lock (exclusively)<br /> 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to<br /> call us with only the mmap lock held (in shared mode), but currently<br /> only runs while holding mmap lock (exclusively) and VMA lock<br /> <br /> Backporting note:<br /> This commit fixes a racy protection that was introduced in commit<br /> b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that<br /> commit claimed to fix an issue introduced in 5.13, but it should actually<br /> also go all the way back.<br /> <br /> [jannh@google.com: v2]