More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method

I know this is no longer the place to request CVEs, but CVEs should be
allocated for the following issues (this is in addition to the two dozen
or so already allocated for CONFIG_VMAP_STACK):

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

Given my recent blog post mentioning CONFIG_VMAP_STACK:
https://grsecurity.net/an_ancient_kernel_hole_is_not_clos...
I believe a CVE should also be allocated to it due to failing to handle
VLAs (which as I've noted have been exploited in the past in the kernel)
and is being marketed as a stack overflow prevention equivalent to what's
present in grsecurity (which it is not).

Here's a fix for a UAF introduced by upstream's refcount_t work (aka introducing
the vulns the defense is supposed to prevent, and it won't be the last):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

Also, over two months ago I mentioned a CONFIG_STRICT_DEVMEM bypass that
still required fixes to the mmap side:
http://seclists.org/oss-sec/2017/q2/76
As predicted, everyone ignored the comment about the mmap side and fixes
were only committed and backported to stable kernels for the read/write
side.  Thus the Secure Boot bypass still exists today, over two months later
in all upstream kernels -- a CVE should be allocated for this separate issue
as well.

Also a shout out to Linus for his recent trade disparagement:
https://www.spinics.net/lists/kernel/msg2540934.html
It's big talk coming from a guy who hasn't protected his users for the past
16 years, who authored the broken stack gap patch that crashed machines and
broke apps in 2010 and introduced the userland ABI changes that are now causing
problems with the proper fix (that oh, surprise, looks a lot like PaX's fix
from 2010).  We've heard these kinds of nonsense claims from Linus before,
like here:
https://lkml.org/lkml/2011/6/6/306
Maybe someone pointed him to it and the embarrassment from realizing he was
completely wrong was too much that he's decided to lash out?

Yes Linus, our patches are such garbage the KSPP can't manage to do anything
other than copy+paste from them, and you're slowly merging them (along
with our registered copyrights).  How do our table scraps taste?

BTW, we're happy to go toe-to-toe with you here in public on actual facts
instead of pathetic ad hominems.

-Brad