Hello! On Fri, 11 Jul 2014 20:31:11 +0300 Alex Efros <[email protected]> wrote:
> There is a risk production won't boot or won't be stable with new > kernel. First one isn't risk at all, 'cos if it won't boot you'll > immediately notice this and just boot previous kernel instead - this > won't even result in noticeable interruption of your services (no > more than usual when you reboot to update kernel). It is not always possible to reboot with the previous kernel. There are datacenters (and not so few) who do not give you remote console access. So in case of boot issue or kernel panic you have to contact someone (who is not always available btw.) and ask nicely to reboot with the old kernel. It happened to me once with such a datacenter, that the new kernel version had some incompatibility with Hyper-V resulting in panic and the interruption was nasty. > Second is a real issue, of course, but chances are it will show itself > several days or even weeks later, and it's really questionable is it > good idea to spend so much time testing new kernel "just in case" in > this situation. > > At same time there is a FACT (i.e. risk with 100% chance to happens) > what your production is vulnerable, and any user (or even someone with > webshell) is able to crash it or even get root and own it. This is not a remote vulnerability. It is a local one (see <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4699>). Usually on production servers there is no local access anyway for arbitrary users. You do not let people to copy executables to your server and run it afterwards. So this vulnerability is not critical at all. You can any time unmask the newer kernel and use it if it fits better for you. There is no need to stabilize it blindly. Regards, Balint
