It was found that EINJ, error injection mechanism, is allowed even if securelevel, a prevention from userspace performing actions that undermine trust in the platform, is enabled. This can have undesirable side-effects, such as causing the platform to mark hardware as needing replacement.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1321639
Upstream patch:
https://github.com/mjg59/linux/commit/d7a6be58edc01b1c66ecd8fcc91236bfbce0a420
It was reported that attempt to move page mapped by aio ring buffer to other node triggers NULL pointer dereference at tracewritebackdirtypage(), because aiofsbackingdevinfo.dev is 0.
Product bug (contains reproducer):
https://bugzilla.redhat.com/showbug.cgi?id=1306851
Upstream patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=42cb14b110a5698ccf26ce59c4441722605a3743
A vulnerability was found in kexec, allowing the attacker to bypass the security mechanism of securelevel/secureboot combination.
When the kernel was booted with UEFI Secure Boot enabled, securelevel is set. If kexec (either through crash or admin action) is then used to load the same kernel, after reboot securelevel is disabled. In this state, the system is missing the protections provided by securelevel, for example kexec may be used to load an unsigned kernel via the legacy system call kexecload. In the securelevel patchset, the state of UEFI Secure Boot is queried in the EFI stub, and sets a bootparams flag to indicate the state of UEFI Secure Boot. This flag is then used in setuparch() to determine the correct state of securelevel. If the kernel is not booted via the EFI stub, securelevel is not set even if UEFI Secure Boot is enabled.
Patch can be found in product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1243998#c3
Upstream patch:
https://github.com/mjg59/linux/commit/4b2b64d5a6ebc84214755ebccd599baef7c1b798
CVE assignment:
http://seclists.org/oss-sec/2015/q4/85
It was found that if an NMI occurred immediately after a SYSCALL or before a SYSRET with the user RSP pointing to the NMI IST stack, the kernel could skip that NMI.
Upstream fix: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=810bc075f78ff2c221536eb3008eac6a492dba2d
Acknowledgements:
Red Hat would like to thank Andy Lutomirski for reporting this issue.
Description of the problem: The uname() syscall since 3.0 with the UNAME26 personality leaks kernel stack memory contents.
Acknowledgements:
Red Hat would like to thank Kees Cook for reporting this issue.
While mm->startstack was protected from cross-uid viewing (commit f83ce3e6b02d5e48b3a43b001390e2b58820389d), the startcode and endcode values were not. This would allow the text location of a PIE binary to leak, defeating ASLR.
Note that the value "1" is used instead of "0" for a protected value since "ps", "killall", and likely other readers of /proc/pid/stat, take startcode of "0" to mean a kernel thread and will misbehave. Thanks to Brad Spengler for pointing this out.
https://lkml.org/lkml/2011/3/11/380
Acknowledgements:
Red Hat would like to thank Kees Cook for reporting this issue.
Description of problem: Structure sockaddrtipc is copied to userland with padding bytes after "id" field in union field "name" unitialized. It leads to leaking of contents of kernel stack memory. We have to initialize them to zero.
Reference: http://marc.info/?l=linux-netdev&m=128854507420917&w=2 http://seclists.org/oss-sec/2010/q4/94
Acknowledgements:
Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.
Description of problem: packetgetnamespkt() doesn't initialize all members of sadata field of sockaddr struct if strlen(dev->name) < 13. This structure is then copied to userland. It leads to leaking of contents of kernel stack memory. We have to fully fill sadata with strncpy() instead of strlcpy().
The same with packetgetname(): it doesn't initialize sllpkttype field of sockaddrll. Set it to zero.
Reference: http://marc.info/?l=linux-netdev&m=128854507220908&w=2 http://seclists.org/oss-sec/2010/q4/94
Acknowledgements:
Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.
Description of problem: Sometimes ax25getname() doesn't initialize all members of fsadigipeater field of fsa struct. This structure is then copied to userland. It leads to leaking of contents of kernel stack memory. We have to initialize them to zero.
Reference: http://marc.info/?l=linux-netdev&m=128854507120898&w=2 http://seclists.org/oss-sec/2010/q4/94
Acknowledgements:
Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.