Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Openvz providers, kernel update time (again)
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Openvz providers, kernel update time (again)

mikhomikho Member, Host Rep

Guess most of you are on the software update list but if you are not, check out the latest update for openvz.
https://wiki.openvz.org/Download/kernel/rhel6/042stab092.3

Thanks to @KuJoe who brought it to my attention.

Comments

  • KernelCare has a patch already out also

  • mikhomikho Member, Host Rep

    KernelCare is really nice for such a low price.

  • AnthonySmithAnthonySmith Member, Patron Provider

    Perhaps I am missing something but this one does not seem critical enough for emergency reboots, the information seems limited to: "when a container could fail to restart, remaining in the 'mounted' state"

    Patching anyway.

  • mikhomikho Member, Host Rep

    @AnthonySmith said:
    Perhaps I am missing something but this one does not seem critical enough for emergency reboots, the information seems limited to: "when a container could fail to restart, remaining in the 'mounted' state"

    Patching anyway.

    Guess its the second part that is interesting.

    The issue could also be triggered by an unprivileged user in any container, resulting in a memory leak and a potential DoS attack.

  • Thanks!

    Patching now.

  • definedcodedefinedcode Member
    edited July 2014

    Patched, thanks.

  • netomxnetomx Moderator, Veteran

    Thanks, will patch

  • we already patched and did all our nodes reboot (even that we use kernel reboot less script)

  • AnthonySmithAnthonySmith Member, Patron Provider

    @setupvps said:
    we already patched and did all our nodes reboot (even that we use kernel reboot less script)

    why reboot then?

  • definedcodedefinedcode Member
    edited July 2014

    I think the language barrier confused him..

  • AnthonySmithAnthonySmith Member, Patron Provider

    oh, thought it sounded odd.

  • @AnthonySmith we did as we did some other updates also and our nodes was working long time so reboot is good

    Thanked by 1AnthonySmith
  • grrr more reboots...

    Thanked by 1Floris
  • KuJoeKuJoe Member, Host Rep

    said: Thanks to @KuJoe who brought it to my attention.

    You're welcome. I was surprised I hadn't received an e-mail from Rack911 yet and there's no word about it on WHT either.

    AnthonySmith said: Perhaps I am missing something but this one does not seem critical enough for emergency reboots

    I had debated while waiting for the OpenVZ repos to sync with the latest kernel if it would warrant an emergency reboot or not and the selling point for me was that the exploit targeted other VPSs on the node and not the node itself.

    My biggest concern was that some malicious kid would sign up for our services and try test out this exploit. If they were crashing other VPSs, we wouldn't notice until we started getting support tickets or if they crashed one of the VPSs that we monitor. Had this exploit been a "can crash the node" exploit, we simply would have updated the kernel and scheduled a reboot for the following weekend and if some kid did decide to crash the node then at least when it booted back up it would be on the new kernel so they couldn't just keep crashing it.

    INIZ said: KernelCare has a patch already out also

    We considered getting KernelCare for our servers but the time between a patch from them and a kernel release from RedHat/OpenVZ was too great for us. They've said that they are working closely with kernel maintainers so they can release patches faster but until then it's not worth it for us. It already takes us extra time to update our kernels because in most cases, we test all new kernels on 2 development nodes before pushing them to production.

    It was nice to see they had a patch within 13 hours of the kernel update though.

Sign In or Register to comment.