OVH uefi boot - freakin' friday f*ck w/ CVE-2026-97631?

Comments

• plumberg Veteran, Megathread Squad

  7:43PM

  Too much effort

  I wiuld power it off

  Thanked by 2OhJohn Saragoldfarb
• OhJohn Member

  7:47PM edited 7:50PM

  @plumberg said: I wiuld power it off

  Just never power it on again

  So you have to reboot to apply all those kernel fixes, but then you are not allowed to reboot because of CVE-2026-97631 - I think i call it a day and start the weekend...

  Thanked by 1plumberg
• remy Veteran

  8:46PM edited 8:51PM

  just change the boot order ?
  bios setup is accessible before default pxe boot

  Just checked on 2 KS-LE-B
  and my configuration is correct

  Old servers will never receive any patch.
  So you have to rely on ovh to filter the network correctly

  Critical flaws everywhere, I consider all my data public at this point.

  Thanked by 1NotFoundException
• OhJohn Member

  9:00PM edited 9:01PM

  @remy said: So you have to rely on ovh to filter the network correctly

  Yeah, ahem, I just have zero trust in them in this regard.

  But blocking ICMP via their edge network firewall could help somewhat (as own sw firewall rules on server won't help) but this would not help for OVH internal traffic nor ipv6.

  So changing boot order would be the best bet atm.
• OhJohn Member

  9:16PM

  @OhJohn said: So changing boot order would be the best bet atm.

  But this would also mean changing it manually each time you want to use rescue mode...
• NotFoundException Member

  9:18PM

  @OhJohn said:

  @OhJohn said: So changing boot order would be the best bet atm.

  But this would also mean changing it manually each time you want to use rescue mode...

  Man, I hate having to use rescue mode every day
• OhJohn Member

  9:21PM

  Yes, rescue mode is last resort and normally not used but i just hate the idea that is not instantly usable once needed... but server security in 2026 is crutches everywhere, fun long gone.
• OhJohn Member

  9:24PM edited 9:24PM

  and the bigger prob is actually b) right now if every reboot adds 11KB of unknown garbage data in the efivars partition until that one is filled up and starts to go on strike.
• NotFoundException Member

  9:27PM

  @OhJohn said:
  Yes, rescue mode is last resort and normally not used but i just hate the idea that is not instantly usable once needed... but server security in 2026 is crutches everywhere, fun long gone.

  I use OLA on 95%+ my dedis anyway, so rescue mode isn't a thing for me any way.

  If there is an IPMI, I prefer to use that and if not, there are plenty of ways you can get around using a rescue mode by your provider.

  https://github.com/minlearn/inst & https://github.com/codebyjawad/restage (vibe coded, but you get the point, if you need it, you could vibe it yourself ^^)
• Maounique Host Rep, Veteran

  9:28PM

  @remy said: I consider all my data public at this point.

  At this point? It is public for years. Doesn't mean the vulnerabilities weren't there, just the CVEs weren't :P
• Mainfrezzer Member

  9:28PM

  Not worried the slightest, it's hard to pull of.

  About the same chance as me having an affair with Huang
• NotFoundException Member

  9:30PM

  @Mainfrezzer said:
  Not worried the slightest, it's hard to pull of.

  About the same chance as me having an affair with Huang

  

  Thanked by 1Mainfrezzer
• OhJohn Member

  9:33PM edited 9:45PM

  any good ideas about efivars cleanup if the firmware garbage collector seems to be broken as well? Or would just a BIOS default reset be the only help there?

  Edit: forget about that, reading would help (not reading the garbage a llm would produce on that or some so threads).
• tux Veteran

  9:45PM

  Google AI says:

  If the firmware's UEFI garbage collector is broken, a BIOS default reset is often not enough because it typically only resets configuration variables rather than reclaiming deleted or fragmented NVRAM blocks.
  To fully clear a stuck NVRAM, you must usually trigger a full physical flash erase or force the firmware into a recovery state.

  1. Software-Level Cleanup (Try First)

  Even if garbage collection is broken, deleting stale entries frees up the logical variable table, which can sometimes prevent immediate "No space left on device" errors.
  • Clear crash dumps. Linux kernels often dump crash logs into /sys/fs/efi/efivars/dump-*. Remove these first using sudo rm /sys/fs/efi/efivars/dump-*.
  • Prune orphaned boot entries. Run efibootmgr to list existing boot entries. Delete old OS loaders or duplicate entries using sudo efibootmgr -b -B.
  • Trigger garbage collection manually. Some UEFI implementations only run garbage collection during a warm reboot after variables are deleted, or when NVRAM usage crosses a specific threshold while entering the BIOS setup menu. Reboot directly into the UEFI setup screen after deleting variables, save, and exit.

  2. Hardware-Level NVRAM Reset (The Real Fix)

  When the firmware fails to reclaim space from deleted variables, the SPI flash chip itself holds stale data that only a hardware reset can wipe.
  • Short the Clear CMOS jumper. Power down completely, unplug the power cable, and bridge the CLRTC or JBAT1 pins on the motherboard for 10 seconds. This forces the chipset to re-initialize the NVRAM region from scratch.
  • Remove the CMOS battery. Unplug the PC, remove the CR2032 coin cell battery, and hold the power button for 15 seconds to drain residual capacitors. Wait 5 to 10 minutes before reinstalling the battery.
  • Reflash the BIOS. Flashing the exact same BIOS version (or an update) via the motherboard's built-in flash utility (like Q-Flash or EZ Flash) or a hardware SPI programmer (flashrom) usually erases and rewrites the entire NVRAM block.

  3. OS-Level Workarounds

  If the board has a chronically buggy UEFI implementation that keeps filling up:
  • Disable kernel pstore logging. Add efi_pstore.pstore_disable=1 to your kernel boot parameters (GRUB_CMDLINE_LINUX_DEFAULT) to stop Linux from writing crash logs to NVRAM.
  • Bypass NVRAM boot registration. When updating GRUB or systemd-boot, pass --no-nvram (e.g., grub-install --target=x86_64-efi --no-nvram) and rely on the fallback bootloader path (/EFI/BOOT/BOOTX64.EFI).
  If you'd like more targeted steps, let me know:
  • Your motherboard model or laptop brand
  • Whether you are hitting ENOSPC errors when running efibootmgr or updating the kernel
  I can check if your specific firmware has known NVRAM quirks or a dedicated recovery method.