A flaw was found in Intel QuickAssist Technology for Linux before version 4.2. An insufficient access control in driver stack may allow an unprivileged user to potentially disclose information via local access. References: https://01.org/security/advisories/intel-oss-10005
Does the problem affect the code from drivers/crypto/qat/ in the kernel or only the out-of-tree modules provided by Intel are vulnerable? If the kernel code is vulnerable too, which kernel versions are affected? It is still not clear.
I agree its not clear. I'm looking into it this week.
Intel have not been forthcoming with details. The only recommendation that I have had from them is to "upgrade" to the fixed package. To be clear, not all systems can or will be using Intel's quick assist technology, you can find out if you're running it by looking at the loaded kernel module. # lsmod |grep qat No results means you're not using it. However the flaw from Intel concerns me in a number of ways: Red Hat does ship Intel QAT technology kernel modules that may include the code that is provided. If the flaw is a complex software-hardware interaction that is also available as a flaw in the kernel module. The information provided on the doc is shown concerns me due to a number of reasons. 1. The patch explaining the flaw is not attached nor reference to a commit that solves the problem. I am also unable to find the location of their git/version control system that houses the repo for confirmation. I am -very- concerned for any opensource project that does not show a level of transparency, but Intel is well within their rights to do so. 2. The second is that the CVSSv3 Score is inconstant with current / usual scoring practices, I'll outline below. Please see https://www.first.org/cvss/specification-document for the cvssv3 specifications. The flaw is rated as: Information Disclosure. CVSS Base Score: 7.8 High The CVSS at this time is : CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H Breaking down the relevant parts. Scope - S:C This implies the scope changed. First specifies this as an 'escape from sandbox' style event. In the code that I've downloaded that was suggested to be fixed I see no sandbox code, so the only possible scope change would be injection into the kernel. Injecting runnable code would mean a privilege escalation, not an information leak. Confidentiality -C:H This implies total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server. In most cases this would be unfettered access to the filesystem or memory. This would fit well with S:C mentioned earlier. Integrity - I:H There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component. This would imply root (or ring0) level control or greater. Availability - A:H H basically at this point means it can reboot/shutdown/stop the process running. Not something non root / normal users can do. My interpretation of this score doesn't mean "information leak" or maybe someone scored it incorrectly.. Information leaks do not -usually- change the availability of the subsystem or entire system. Intel has been contacted, the official response is: > Intel does not discuss the specifics of a vulnerability. > The mitigation is to update to the version of quick assist as outlined in INTEL-OSS-10005, why is that not sufficient? So.. I still understand its Intel policy not to talk about the flaw, but the above makes me -considerably- more concerned than a usual information leak. In the meantime, I would strongly recommend to blacklist the module and cease using the QAT provided by Red Hat. You can blacklist a kernel module with the command: # echo "blacklist intel_qat" > /etc/modprobe.d/blacklist-intel_qat.conf You may also need to blacklist the specific kernel module that is provided by the hardware, you can find it by looking at the loaded modules and parsing out qat. # lsmod |grep qat For example: # echo "blacklist qat_dh895xcc" > /etc/modprobe.d/blacklist-qat_dh895xcc.conf The system may need to be restarted for these changes to take effect. I have pressed Intel again for an update with more information, Might have to be a full rebase which will take some time and testing if they are not more forthcoming with flaw information. In the mean time blacklisting the module is the only mechanism I can recommend to mitigate this flaw, the QAT functionality however will be impaired. If Intel come back with more information I will update this bugzilla.
I see. Thanks for the detailed explanation.
Updated response from intel: ----------- I have investigated this issue, and whether the QAT driver that ships with Red Hat is impacted. It is not. The vulnerability exists in the driver used to allocate pinned contiguous memory on behalf of a user process. This driver is not included in the QAT software that is included in the kernel. ----------- So with that in mind, i'm deleting trackers and setting kernel as not affected.
External References: https://01.org/security/advisories/intel-oss-10005