Comment 8 for bug 1840778

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.