CVE-2024-35994

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: uefisecapp: Fix memory related IO errors and crashes<br /> <br /> It turns out that while the QSEECOM APP_SEND command has specific fields<br /> for request and response buffers, uefisecapp expects them both to be in<br /> a single memory region. Failure to adhere to this has (so far) resulted<br /> in either no response being written to the response buffer (causing an<br /> EIO to be emitted down the line), the SCM call to fail with EINVAL<br /> (i.e., directly from TZ/firmware), or the device to be hard-reset.<br /> <br /> While this issue can be triggered deterministically, in the current form<br /> it seems to happen rather sporadically (which is why it has gone<br /> unnoticed during earlier testing). This is likely due to the two<br /> kzalloc() calls (for request and response) being directly after each<br /> other. Which means that those likely return consecutive regions most of<br /> the time, especially when not much else is going on in the system.<br /> <br /> Fix this by allocating a single memory region for both request and<br /> response buffers, properly aligning both structs inside it. This<br /> unfortunately also means that the qcom_scm_qseecom_app_send() interface<br /> needs to be restructured, as it should no longer map the DMA regions<br /> separately. Therefore, move the responsibility of DMA allocation (or<br /> mapping) to the caller.