CVE-2019-11811:use-after-free upon attempted read access to /proc/ioports after the ipmi_si module is removed

[zhao.shuai]

Brief Description
-----------------
A flaw was found in the Linux kernel's implementation of IPMI (remote baseband access). An attacker, with local access to read /proc/ioports, may be able to create a use-after-free condition when the kernel module is unloaded which may result in privilege escalation.
Find out more about CVE-2019-11811 from the MITRE CVE dictionary dictionary and NIST NVD.

Severity
--------
Major: System/Feature is usable but degraded

Steps to Reproduce
------------------
This flaw has been rated as "Moderate" as the attacker needs to be able to abuse this flaw in a very narrow race condition of the kernel module being unloaded. This scoring system from this flaw differentiates from other sources as the attacker must have a local account to be able to read the file (/proc/ioports) while the module is unloaded. None of the above actions are 'network facing' attack vectors.

Detailed description path
------------------
https://access.redhat.com/security/cve/cve-2019-11811

[Ghada Khalil (gkhalil)]

This CVE meets the starlingx policy for providing a fix to stx.2.0 as well as master.

[Long.Li (long.li)]

we are investigating on it,
if make any progress,
we will update on launchpad.

[Zhang Zhiguo (zhangzhg)]

According to the description of the https://access.redhat.com/security/cve/cve-2019-11811 chain URL, the cve-2019-11811 security vulnerability requires upgrading the kernel to 3.10.0-957.27.2.

However, only the std src package can be found from the official website http://vault.centos.org/7.6.1810/updates/Source/SPackages/, and the corresponding rt src package is not found http://vault.centos.org/7.6 .1810/rt/Source/SPackages/,
So download the rt src package from a third party http://linuxsoft.cern.ch/cern/centos/7.6.1810/rt/Source/SPackages/.

Thanks Shuicheng for help.

[Zhang Zhiguo (zhangzhg)]

Std patches have been modified, continue to modify rt patches.

[Zhang Zhiguo (zhangzhg)]

Kernel patches have been modified and are being compiled.

[zhao.shuai (zhao.shuai.neusoft)]

Hi Zhiguo, please don't change the "information type" setting,
because this is a security vulnerability issue, Please keep it private. Thx

[Zhang Zhiguo (zhangzhg)]

VM Allinone simplex is being tested.

[zhao.shuai (zhao.shuai.neusoft)]

From Jim teacher:
A quick look at the 957 kernel shows that it doesn't look vulnerable to this CVE.
Redhat claims the fix is in 3.10.0-957.27.2, it is listed in the changelog.

BUT if you look under the hood of the upstream fix, there are 3 components to it:
1. Put the call to the i/o cleanup procvar back in the out_err path in try_smi_init.
2. Move the setting of the i/o cleanup procvar in port_setup at the end of the call once you know port setup was successful.
3. Same as 2 but for mem_setup.
Component 1 actually fixes the CVE.
Component 2 and 3 just eliminate warning messages in the case where setup wasn't successful, but you try to clean up anyway. ie. release null blocks of memory

In the case of 957.27.2, they only do 2 and 3 because 1 isn't an issue, the cleanup call is already here. So they fixed something that wasn't broken, only to eliminate the possibility of a couple of warning messages.

It doesn't look like CentOS ever released a vulnerable kernel. They picked up the fix in 1053 (internal release), and the previous external release before that was 957.27.2 . It looks like internal churn around. 1020 might have introduced the issue, but I can't tell for sure since they never externally released 1020.

From Ghada teacher:
Jim Somerville was looking at this CVE (unrelated to StarlingX) and he concluded that the CentOS 957.21.3 (which is the version in StarlingX) is not vulnerable. I'm sharing his analysis below with you. If you come to the same conclusion, we can abort the kernel upversion and stick with 957.21.3.

[Cindy Xie (xxie1)]

As Jim pointed out, we already have the core fixes in .21 kernel on master, decision has made to not upgrade the kernel to .27 this time. Mark this as "Fix released".

[Ghada Khalil (gkhalil)]

Setting the status to "Invalid" is more appropriate given we didn't merge a fix for this. The conclusion was that the starlingx kernel is not vulnerable to this issue.

[Ghada Khalil (gkhalil)]

Note: The fix for this CVE will be picked up anyway as we are upgrading the kernel to 1062 for pick up other CVEs. See:
https://bugs.launchpad.net/starlingx/+bug/1849206
https://bugs.launchpad.net/starlingx/+bug/1847817
https://bugs.launchpad.net/starlingx/+bug/1849209

[Ghada Khalil (gkhalil)]

This was actually resolved in stx.2.0 & newer releases via https://bugs.launchpad.net/starlingx/+bug/1849209
Marking as Fix Released / Duplicate