@ljs I still do not understand what's the problem with NULL
pointers. If you see it, just don't dereference it. It's easy. All that memory safety concept is just a hype.
@ljs
Kernels that don't keep something useful and interesting at @0x0 are just wrong.
@ljs lol, wtf is that first reply. I haven’t been on twitter in ages but it seems to be even more insane these days
@ljs yeah, I assumed that you just hadn’t noticed it :)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index e6c469b323ccb..d1a936451153b 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -534,10 +534,12 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code, unsigned long ad
from_kuid(&init_user_ns, current_uid()));
}
- if (address < PAGE_SIZE && !user_mode(regs))
+ if (address < PAGE_SIZE && !user_mode(regs)) {
pr_alert("BUG: kernel NULL pointer dereference, address: %px\n",
(void *)address);
- else
+ // do nothing to prevent crash
+ return;
+ } else
pr_alert("BUG: unable to handle page fault for address: %px\n",
(void *)address);
Thank me later.
@oleksandr @ljs I don't disagree, but there is usually a question of who should check.
Should you check "this" in all methods? Should you check all byref arguments? Should you check in an api called internally for something that should always be valid? Often the check is moved out to the first place a pointer is checked. But over time, this may lead to mistakes.
Any time you don't check, you risk this bug.
@ljs @oleksandr I know, just expanding on various stupid decisions made by C/C++
@oleksandr @ljs More over if it was something like std::optional, then you would get an uncaught exception instead. Almost exactly the same issue. Though rust requires you to match on std::option but that is just fluf really and does not cause much safety except for in the mind.