Changes in handling Linux Kernel CVEs

As a lot of the allocated CVEs are not exploitable by an attacker in the Linux kernels of SUSE products and also similar to handling by other industry players SUSE will not address CVEs of following categories:

* Code SUSE does not build into its kernels

CVEs targeting code that is not enabled in SUSE kernels through CONFIG options. That includes drivers which are not enabled but also debugging code like VM_BUG_ON etc.

* Testing infrastructure

Fixes for tools/testing that are not meant to be run on production systems.

* WARN_ON fixes

SUSE default and recommended configurations that do not enable panic_on_warn and so only triggering a warning.

* small GFP_KERNEL allocation failures triggering NULL ptr

Fixes adding allocation failure checks to prevent from NULL ptr crashes for very small allocations. If the allocation request is GFP_KERNEL and the allocation size is small (<= PAGE_ALLOC_COSTLY_ORDER) then an allocation failure is practically impossible. This means that those fixes are never tested and therefore risky to introduce unwanted side effects which would be harder to notice. The benefit of the fix is therefore much smaller than the risk fixing it might cause.

* debugfs only fixes

debugfs is a debugging interface to kernel functionality that doesn't pass regular scrutiny that all other kernel API/ABIs are getting. Therefore it is not recommended to have debugfs enabled; it shouldn't be mounted on production systems and if there is a need for that it should be limited to privileged users only. On SUSE debugfs is limited to root only.

* boot time crashes

Fixes for boot time crashes, either as a result of an unexpected HW configuration (LPAR configurations, device tree misconfiguration, BIOS/FW bugs) or as a result of kernel command line misconfiguration.

* memory leaks which cannot be directly triggered from the userspace

CVEs assigned for memory leaks which are either impractical to trigger (e.g. clean up not done on module unloading) or on a failure path which is not controllable by an attacker.

* HW failure only triggerable issue

kernel crashes triggered by a HW failure are not considered a security threat unless they can be directly triggered by a user.

Please note that some failure modes are generally not recoverable and the only effective protection is physical inaccessibility (e.g. storage connectivity) but there are use cases which are primarily focused on the 3rd party HW controlled by potential attacker (e.g. USB stick kiosk). The latter is considered a real security attack vector while the former is not.

SUSE will also decide on a case-by-case basis:

* system root/CAP_SYSADMIN only triggerable issues

If a crash/use after free(UAF) or similar issue is only triggered by a privileged user then those fixes are not considered security relevant because such a user can already compromise the security of the system. This would include interfaces like fault injection (e.g. HW poisoning), sysctl/sysfs/proc configurations that might trigger crashes/UAF etc, kernel modules loading and unloading and many others.

For untrusted root scenarios (kernel lockdown, e.g. in secure boot) issues which allow to bypass lockdown constraints are considered security relevant.

The issues SUSE will not fix will be marked as "Won't Fix" on the SUSE CVE pages.

Please feel free to reach out to us if you think a CVE is not matching one of those categories, but still classified as Won't fix by either opening a support case or write an email to security[at]suse.de.