Kernel Oops NULL Pointer Dereference After Update — Troubleshooting
A company runs a critical web server on a custom-built Linux distribution. The server has been stable for months, but after a recent kernel update from version 5.10 to 5.15, the server experiences intermittent crashes. The crashes occur under heavy load and are accompanied by kernel oops messages mentioning a NULL pointer dereference in a network driver. The network driver is a third-party module that was compiled against the old kernel. The system administrator has recompiled the module against the new kernel, but the crashes persist. The server has 64 GB of RAM and uses a bonded network interface with two 10 GbE NICs. The kernel oops trace points to a function in the bonding driver. Which of the following is the most likely cause of the crashes?
Quick Answer
The answer is to check the kernel configuration changes between versions 5.10 and 5.15 that affect the bonding driver. This is correct because a kernel oops null pointer dereference after update network driver that persists even after recompiling the third-party module points squarely to an internal kernel API or data structure change—specifically in the in-tree bonding driver, not the out-of-tree NIC module. The oops trace itself confirms the fault lies within the bonding code, meaning the kernel’s own networking stack has changed in a way that breaks compatibility with the old driver’s assumptions. On the LPIC-2 exam, this scenario tests your understanding that kernel updates can alter internal interfaces (like `struct net_device` or locking primitives) even when external modules are recompiled, and that the bonding driver is part of the kernel tree. A common trap is to keep blaming the third-party module, but the real culprit is often a subtle kernel configuration shift. Memory tip: “If the oops points to the kernel’s own code, don’t patch the module—patch your config.”
⚠ Common exam trap
Test-takers frequently assume recompiling the third-party module against the new kernel is sufficient, overlooking that the crash originates in the in-tree bonding driver, which must also be compatible with the kernel version and may require kernel configuration adjustments or backported patches.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Check the kernel configuration changes between versions 5.10 and 5.15 that affect the bonding driver.
The crashes persist after recompiling the third-party network driver, and the oops trace points to the bonding driver. This indicates that the issue is likely due to changes in the kernel's internal APIs or data structures between versions 5.10 and 5.15 that affect the bonding driver, not the third-party module. The bonding driver is part of the kernel itself, so it must be compatible with the new kernel version; checking kernel configuration changes (e.g., modifications to `struct net_device`, bonding sysfs interfaces, or locking mechanisms) is the appropriate next step.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the system memory to reduce memory pressure.
Why it's wrong here
Memory pressure is not the issue; the problem is a NULL pointer dereference.
- ✗
Update the firmware on the network interface cards.
Why it's wrong here
Firmware update is unlikely to fix a kernel API incompatibility.
- ✓
Check the kernel configuration changes between versions 5.10 and 5.15 that affect the bonding driver.
Why this is correct
Kernel API changes in the bonding driver could cause the third-party module to dereference a NULL pointer.
- ✗
Recompile the network driver module with debugging enabled.
Why it's wrong here
Recompiling with debugging may provide more info but does not fix the underlying issue.
Go deeper
Related to this question
About these practice questions
Courseiva writes every LPIC-2 question from scratch — 507 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on LPIC-2
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A developer has compiled a custom kernel with a new feature. The kernel modules are installed in /lib/modules/$(uname -r)/. However, when the system boots, the kernel fails to load some modules with 'Exec format error'. What is the most likely cause?
hard- A.The kernel configuration has disabled module loading.
- ✓ B.The modules were compiled against a different kernel version.
- C.The modules have incorrect file permissions.
- D.The modules are not properly ordered in the dependency file.
Why B: The 'Exec format error' indicates that the kernel module binary is incompatible with the running kernel. This most commonly occurs when modules are compiled against a different kernel version (e.g., different kernel source tree or configuration), as the module's vermagic string must exactly match the kernel's vermagic. The kernel's module loader checks this version magic before loading; a mismatch causes the exec format error.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-2 practice question is part of Courseiva's free LPI certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LPIC-2 exam.