Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: core: fix race in driver_override_show() and use core helper<br /> <br /> The driver_override_show function reads the driver_override string<br /> without holding the device_lock. However, the store function modifies<br /> and frees the string while holding the device_lock. This creates a race<br /> condition where the string can be freed by the store function while<br /> being read by the show function, leading to a use-after-free.<br /> <br /> To fix this, replace the rpmsg_string_attr macro with explicit show and<br /> store functions. The new driver_override_store uses the standard<br /> driver_set_override helper. Since the introduction of<br /> driver_set_override, the comments in include/linux/rpmsg.h have stated<br /> that this helper must be used to set or clear driver_override, but the<br /> implementation was not updated until now.<br /> <br /> Because driver_set_override modifies and frees the string while holding<br /> the device_lock, the new driver_override_show now correctly holds the<br /> device_lock during the read operation to prevent the race.<br /> <br /> Additionally, since rpmsg_string_attr has only ever been used for<br /> driver_override, removing the macro simplifies the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels<br /> <br /> MHI stack offers the &amp;#39;auto_queue&amp;#39; feature, which allows the MHI stack to<br /> auto queue the buffers for the RX path (DL channel). Though this feature<br /> simplifies the client driver design, it introduces race between the client<br /> drivers and the MHI stack. For instance, with auto_queue, the &amp;#39;dl_callback&amp;#39;<br /> for the DL channel may get called before the client driver is fully probed.<br /> This means, by the time the dl_callback gets called, the client driver&amp;#39;s<br /> structures might not be initialized, leading to NULL ptr dereference.<br /> <br /> Currently, the drivers have to workaround this issue by initializing the<br /> internal structures before calling mhi_prepare_for_transfer_autoqueue().<br /> But even so, there is a chance that the client driver&amp;#39;s internal code path<br /> may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is<br /> called, leading to similar NULL ptr dereference. This issue has been<br /> reported on the Qcom X1E80100 CRD machines affecting boot.<br /> <br /> So to properly fix all these races, drop the MHI &amp;#39;auto_queue&amp;#39; feature<br /> altogether and let the client driver (QRTR) manage the RX buffers manually.<br /> In the QRTR driver, queue the RX buffers based on the ring length during<br /> probe and recycle the buffers in &amp;#39;dl_callback&amp;#39; once they are consumed. This<br /> also warrants removing the setting of &amp;#39;auto_queue&amp;#39; flag from controller<br /> drivers.<br /> <br /> Currently, this &amp;#39;auto_queue&amp;#39; feature is only enabled for IPCR DL channel.<br /> So only the QRTR client driver requires the modification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls<br /> <br /> The size of the data behind of scontrol-&gt;ipc_control_data for bytes<br /> controls is:<br /> [1] sizeof(struct sof_ipc4_control_data) + // kernel only struct<br /> [2] sizeof(struct sof_abi_hdr)) + payload<br /> <br /> The max_size specifies the size of [2] and it is coming from topology.<br /> <br /> Change the function to take this into account and allocate adequate amount<br /> of memory behind scontrol-&gt;ipc_control_data.<br /> <br /> With the change we will allocate [1] amount more memory to be able to hold<br /> the full size of data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: mtk-smi: fix device leak on larb probe<br /> <br /> Make sure to drop the reference taken when looking up the SMI device<br /> during larb probe on late probe failure (e.g. probe deferral) and on<br /> driver unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: mtk-smi: fix device leaks on common probe<br /> <br /> Make sure to drop the reference taken when looking up the SMI device<br /> during common probe on late probe failure (e.g. probe deferral) and on<br /> driver unbind.

HCL BigFix RunBookAI is affected by a Unvalidated Command Input / Potential Command Smuggling vulnerability. A flaw in a component&amp;#39;s input handling was identified that could permit unauthorized command execution.

HCL BigFix RunBookAI is affected by a Continued availability of Less-Secure “Input Text” Vulnerability . A component contains a security weakness in its input handling implementation, increasing the risk of misconfiguration and operational errors.

A flaw was found in Keylime. An attacker with root access on an enrolled monitored machine, where the Keylime agent runs, can exploit a vulnerability in the Keylime verifier. The verifier uses a hardcoded challenge nonce for Trusted Platform Module (TPM) quote attestation instead of a cryptographically random value. This allows the attacker to stockpile valid TPM quotes and replay them to evade detection after compromising the system. This issue affects only the push model deployment.

HCL DFXAnalytics is affected by a Using Components with Known Vulnerabilities flaw where the application utilizes unpatched libraries or sub-components, which could allow an attacker to identify and exploit publicly known security vulnerabilities to gain unauthorized access or compromise the application.

HCL DFXAnalytics is affected by an Insufficient Transport Layer Protection vulnerability where data is transmitted over the network without encryption, which could allow an attacker to compromise the confidentiality, integrity, and authentication of sensitive information.

HCL DFXAnalytics is affected by an Improper Error Handling vulnerability where the application exposes detailed stack traces in responses, which could allow an attacker to gain insights into the application&amp;#39;s internal structure, code logic, and environment configurations.

HCL DFXAnalytics is affected by an Insecure Security Header Configuration vulnerability where the application utilizes the outdated X-XSS-Protection header, which could allow an attacker to exploit browser-specific rendering flaws or bypass security controls that should instead be managed by a robust Content Security Policy (CSP).