BUG: unable to handle kernel NULL pointer dereference at 0000000000000010

Kernel Oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010

Linux & Unix Intermediate 👁 6 views 📅 Jul 1, 2026

This happens when a driver tries to use a memory address that doesn't exist. Usually after plugging in a new device or loading a buggy kernel module.

You're working on a server, maybe an old Dell PowerEdge R720 running Ubuntu 22.04 or a CentOS 7 box, and you plug in a USB-to-serial adapter or load a new kernel module for a RAID card. Then the screen freezes. Sometimes you see it in the logs, sometimes the machine just locks up hard. You reboot, check dmesg, and there it is — BUG: unable to handle kernel NULL pointer dereference at 0000000000000010.

This oops is the kernel's way of saying "I tried to use something at memory address 0x10, and that address doesn't belong to any valid memory." It's almost always caused by a buggy driver. Maybe the driver developer forgot to check if a pointer is null before using it. Or the hardware returned a bad value and the driver didn't handle it.

Let's get the real fix. You don't need to recompile the kernel. You need to find the bad driver and stop it from loading.

Step 1: Capture the oops details

First, get the full oops output. Run this right after the crash or after you reboot and log back in:

dmesg | grep -A 20 'BUG: unable to handle kernel NULL pointer dereference'

You should see lines like this:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [] some_driver_function+0x10/0x50 [bad_driver]
PGD 0
Oops: 0000 [#1] SMP

The key part is the IP line. It tells you which driver and which function caused the crash. In this example, [bad_driver] is the culprit. Write down that driver name.

Step 2: Check if the driver is a module or built into the kernel

Run this to see if the driver is a module:

lsmod | grep bad_driver

If you get output like bad_driver 12345 0, it's a module. That's good — you can just blacklist it. If you see nothing, the driver might be built into the kernel. We'll handle that later.

Step 3: Blacklist the bad driver (if it's a module)

Create a new blacklist file. Be specific — use a file name that matches the driver:

sudo nano /etc/modprobe.d/blacklist-bad_driver.conf

Add this line:

blacklist bad_driver

Save and exit. Now update the initial ramdisk to make sure the driver doesn't load during boot:

sudo update-initramfs -u

On CentOS/RHEL, it's:

sudo dracut -f

After that, reboot. Check dmesg again — the oops should be gone.

Step 4: What if the driver is built into the kernel?

If lsmod didn't show the driver, it's compiled into the kernel. Blacklisting won't work. You have two choices: upgrade the kernel to a newer version that has the fix, or downgrade the kernel to a version before the bug was introduced. I usually check the kernel changelog for the driver name. For example, if the driver is i915 (Intel graphics), I'd search for i915 null pointer dereference fix and find the exact kernel commit that fixed it. Then install a kernel that includes that commit.

On Ubuntu, you can install a mainline kernel from the Ubuntu Kernel PPA. On CentOS, you might need to use ELRepo or compile your own. It's a pain, but it's the right fix.

Step 5: If the oops still happens after blacklisting

Check these three things:

  1. Did you blacklist the right driver? Look at the IP line again. Sometimes the crash is in a helper module that gets loaded by the main driver. You might need to blacklist the parent driver too. For example, usb_storage might crash, but the actual problem is in uas. Blacklist both.
  2. Is the driver loaded automatically? Some drivers get pulled in by other modules. Run modprobe -r bad_driver to unload it, then check dmesg for any module dependency errors. You might need to add install bad_driver /bin/true to your blacklist file instead of just blacklist.
  3. Is the hardware faulty? Rare, but possible. If you unload the driver and the oops still happens, try removing the device physically. If the oops stops, the hardware is sending bad data. Replace it.
One time I had a client whose HP ProLiant DL380 kept oopsing with this exact error. Turned out the RAID controller firmware was too old and the driver hpsa didn't know how to talk to it properly. We updated the firmware, and the oops vanished.

That's the real fix. No need to recompile the kernel or rebuild the whole system. Find the driver, blacklist it, or upgrade the kernel. You're back up and running.

Was this solution helpful?