Kernel Panic: Memory Allocation Failure on Linux 6.x

When This Happens

You're running a Linux 6.x server, maybe a database or a web app, and suddenly everything freezes. The console shows:

Kernel panic - not syncing: Out of memory and no killable processes

This usually hits when your app requests memory faster than the kernel can hand it out. I've seen it on a PostgreSQL server that tried to allocate 10GB of shared buffers on a box with only 8GB of physical RAM and no swap. The kernel panicked instead of gracefully killing the process.

Root Cause

What's actually happening here is the kernel's memory manager can't reclaim any more pages. Normally, the OOM killer steps in and kills a process to free memory. But when vm.overcommit_memory is set to 2 (strict overcommit), the kernel refuses to overcommit memory at all. It checks every allocation against total available RAM + swap. If the allocation would exceed that, it fails immediately. But sometimes—especially with kernel threads or processes that hold critical locks—the OOM killer can't find a process to kill without breaking the system. So the kernel panics.

The reason this happens on Linux 6.x more than older versions is the memory management code got stricter about failing allocations that could lead to undefined behavior. It's a trade-off: safer memory accounting vs. system stability under pressure.

The Fix

You've got two choices: add more swap/memory, or change the overcommit setting. I'm going to show you the setting fix because it's faster and works for most cases.

1. Check current overcommit setting
   Run this as root:
   

   cat /proc/sys/vm/overcommit_memory

   If it prints 2, that's the strict mode causing your panic.
2. Change it to 1
   Run:
   

   echo 1 > /proc/sys/vm/overcommit_memory

   This sets the kernel to always overcommit memory. It means the kernel will let processes allocate more memory than physically exists, hoping they won't actually use it all at once.
3. Make it permanent
   Edit /etc/sysctl.conf and add:
   

   vm.overcommit_memory = 1

   Then run sysctl -p to apply it.
4. Add swap if you can
   Even with overcommit set to 1, no swap means the kernel has no breathing room. Add swap with:
   

   fallocate -l 4G /swapfile
   chmod 600 /swapfile
   mkswap /swapfile
   swapon /swapfile

   Then add to /etc/fstab:
   /swapfile none swap sw 0 0
5. Reboot to test
   A reboot isn't strictly required, but I like to confirm the sysctl setting survives boot. Reboot and check cat /proc/sys/vm/overcommit_memory again.

If It Still Fails

If you still get panics after the fix, here's what to check:

• Memory leak in your app — Run top or htop and look at RES memory over time. If it keeps climbing, your app's leaking. Fix the leak, not the kernel.
• Swap is full — Even with overcommit, if swap fills up completely, the kernel can panic. Add more swap or reduce memory usage.
• Kernel bug — On some hardware like AMD EPYC 7002 series with Linux 6.1-6.3, there's a known bug where memory allocation fails despite available memory. Update to 6.4+ or apply the patch from this commit.

If you're still stuck, boot with panic=10 kernel parameter so it reboots automatically, then analyze the crash dump with kdump and crash tool. But 90% of the time, the overcommit fix alone stops the panic.