In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: uefisecapp: fix efivars registration race Since the conversion to using the TZ allocator, the efivars service is registered before the memory pool has been allocated, something which can lead to a NULL-pointer dereference in case of a racing EFI variable access. Make sure that all resources have been set up before registering the efivars.

IBM EntireX 11.1 could allow a local user to unintentionally modify data timestamp integrity due to improper shared resource synchronization.

In the Linux kernel, the following vulnerability has been resolved: ice: Don't process extts if PTP is disabled The ice_ptp_extts_event() function can race with ice_ptp_release() and result in a NULL pointer dereference which leads to a kernel panic. Panic occurs because the ice_ptp_extts_event() function calls ptp_clock_event() with a NULL pointer. The ice driver has already released the PTP clock by the time the interrupt for the next external timestamp event occurs. To fix this, modify the ice_ptp_extts_event() function to check the PTP state and bail early if PTP is not ready.

An unprivileged user can delete arbitrary files on a Linux system running ENSLTP 10.5.1, 10.5.0, and 10.2.3 Hotfix 1246778 and earlier. By exploiting a time of check to time of use (TOCTOU) race condition during a specific scanning sequence, the unprivileged user is able to perform a privilege escalation to delete arbitrary files.

In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).

Dell BIOS contains a Time-of-check Time-of-use vulnerability. A local authenticated malicious user could\u00a0potentially exploit this vulnerability by using a specifically timed DMA transaction during an SMI to gain arbitrary code execution on the system.

DMA transactions which are targeted at input buffers used for the SdHostDriver software SMI handler could cause SMRAM corruption through a TOCTOU attack. DMA transactions which are targeted at input buffers used for the software SMI handler used by the SdHostDriver driver could cause SMRAM corruption through a TOCTOU attack. This issue was discovered by Insyde engineering based on the general description provided by Intel's iSTARE group. Fixed in kernel 5.2: 05.27.25, kernel 5.3: 05.36.25, kernel 5.4: 05.44.25, kernel 5.5: 05.52.25 https://www.insyde.com/security-pledge/SA-2022050

DMA transactions which are targeted at input buffers used for the SdMmcDevice software SMI handler could cause SMRAM corruption through a TOCTOU attack. DMA transactions which are targeted at input buffers used for the software SMI handler used by the SdMmcDevice driver could cause SMRAM corruption through a TOCTOU attack. This issue was discovered by Insyde engineering based on the general description provided by Intel's iSTARE group. This was fixed in kernel 5.2: 05.27.25, kernel 5.3: 05.36.25, kernel 5.4: 05.44.25, kernel 5.5: 05.52.25 https://www.insyde.com/security-pledge/SA-2022054

DMA transactions which are targeted at input buffers used for the NvmExpressDxe software SMI handler could cause SMRAM corruption through a TOCTOU attack. DMA transactions which are targeted at input buffers used for the software SMI handler used by the NvmExpressDxe driver could cause SMRAM corruption through a TOCTOU attack. This issue was discovered by Insyde engineering based on the general description provided by Intel's iSTARE group. This issue was fixed in kernel 5.2: 05.27.25, kernel 5.3: 05.36.25, kernel 5.4: 05.44.25, kernel 5.5: 05.52.25 https://www.insyde.com/security-pledge/SA-2022055

Race condition due to the lack of resource lock which will be concurrently modified in the memcpy statement leads to out of bound access in Snapdragon Auto, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables in APQ8009, APQ8017, APQ8053, APQ8096AU, APQ8098, MDM9206, MDM9207C, MDM9607, MDM9640, MDM9650, MSM8905, MSM8909W, MSM8939, MSM8953, MSM8996AU, MSM8998, Nicobar, QCN7605, QCS405, QCS605, QM215, SDA660, SDA845, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDM710, SDM845, SDX20, SDX24, SM6150, SM7150, SM8150

A time-of-check to time-of-use (TOCTOU) bug in handling of IOCTL (input/output control) requests. This TOCTOU bug leads to an out-of-bounds write vulnerability which can be further exploited, allowing an attacker to gain full local privilege escalation on the system.This issue affects Avast/Avg Antivirus: 23.8.

DMA transactions which are targeted at input buffers used for the AhciBusDxe software SMI handler could cause SMRAM corruption (a TOCTOU attack). DMA transactions which are targeted at input buffers used for the software SMI handler used by the AhciBusDxe driver could cause SMRAM corruption through a TOCTOU attack. This issue was discovered by Insyde engineering based on the general description provided by Intel's iSTARE group, Fixed in kernel 5.2: 05.27.23, kernel 5.3: 05.36.23, kernel 5.4: 05.44.23, kernel 5.5: 05.52.23 https://www.insyde.com/security-pledge/SA-2022047

DMA transactions which are targeted at input buffers used for the HddPassword software SMI handler could cause SMRAM corruption through a TOCTOU attack. DMA transactions which are targeted at input buffers used for the software SMI handler used by the HddPassword driver could cause SMRAM corruption through a TOCTOU attack..This issue was discovered by Insyde engineering based on the general description provided by Intel's iSTARE group. Fixed in kernel Kernel 5.2: 05.27.23, Kernel 5.3: 05.36.23, Kernel 5.4: 05.44.23, Kernel 5.5: 05.52.23 https://www.insyde.com/security-pledge/SA-2022051

Possible memory corruption due to Improper handling of hypervisor unmap operations for concurrent memory operations in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile

An issue was discovered in IhisiSmm in Insyde InsydeH2O with kernel 5.0 through 5.5. The IhisiDxe driver uses the command buffer to pass input and output data. By modifying the command buffer contents with DMA after the input parameters have been checked but before they are used, the IHISI SMM code may be convinced to modify SMRAM or OS, leading to possible data corruption or escalation of privileges.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the FvbServicesRuntimeDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the AhciBusDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the NvmExpressDxe buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated by using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the link data to SMRAM before checking it and verifying that all pointers are within the buffer.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the IdeBusDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the HddPassword shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the StorageSecurityCommandDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the SdHostDriver buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated by using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the link data to SMRAM before checking it and verifying that all pointers are within the buffer.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the VariableRuntimeDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This issue was fixed in the kernel, which also protected chipset and OEM chipset code.

Memory corruption in display due to time-of-check time-of-use of metadata reserved size in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables

Time of Check - Time of Use (TOCTOU) vulnerability in Quick Heal Total Security prior to 12.1.1.27 allows a local attacker to achieve privilege escalation, potentially leading to deletion of system files. This is achieved through exploiting the time between detecting a file as malicious and when the action of quarantining or cleaning is performed, and using the time to replace the malicious file by a symlink.

Memory corruption in Core due to time-of-check time-of-use race condition during dump collection in trust zone.

An issue was discovered in Insyde InsydeH2O with kernel 5.1 through 5.5. DMA attacks on the SdMmcDevice buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated by using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the link data to SMRAM before checking it and verifying that all pointers are within the buffer.

An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the PnpSmm shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.

Potential vulnerabilities have been identified in the system BIOS of certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure.

Automox Agent for macOS before version 39 was vulnerable to a time-of-check/time-of-use (TOCTOU) race-condition attack during the agent install process.

Potential vulnerabilities have been identified in the system BIOS of certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure.