Kernel Oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
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:
- 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_storagemight crash, but the actual problem is inuas. Blacklist both. - Is the driver loaded automatically? Some drivers get pulled in by other modules. Run
modprobe -r bad_driverto unload it, then checkdmesgfor any module dependency errors. You might need to addinstall bad_driver /bin/trueto your blacklist file instead of justblacklist. - 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?