It was a null pointer deref apparently... (lol)

@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.

@oleksandr the null hypothesis

@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

@dougmerritt yeah I have a patch series to keep plain text system passwords there

@ljs
You have my vote.

@sven lol christ I hadn't even fucking noticed that. Ugh.

Might edit and crop that... madness

@sven Done lol. Just to be clear I find that opinion revolting and bullshit ffs.

Twitter is a mess yes

@oleksandr @ljs https://www.youtube.com/watch?v=HSmKiws-4NU

@dougmerritt and my axe.

@ljs yeah, I assumed that you just hadn’t noticed it :)

@sven mate forwarded me the post was probably pointing out how ludicrous that reply was, I got nerdsniped by the null ptr deref

@lkundrak @ljs

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.

@gigantos @oleksandr I think he's shit posting? ;)

@ljs @oleksandr I know, just expanding on various stupid decisions made by C/C++

@ljs @gigantos Sir, I'm not shitposting, I'm highlighting issues with shitcoding. Otherwise, feel free to implement "sarcasm" spoiler for ActivityPub as a nice addition to "content warning".

@ljs i still that in this case more relevant than what type of memory error we are talking about, is how long the rollback process took ;-)

i'd expect large cloud companies to test their emergency procedures, not just red teaming but also simulate faulty patches getting through.

@jarkko see my toot feed, I say this. This one was just amusement at what the issue was.

I'm happy I got to see this sight in my lifetime ;-) The blue egg of death.

@jarkko @ljs was that pic real though?

@vbabka @jarkko as real as your talent

@vbabka @ljs does it matter ;-)

@jarkko @ljs https://youtu.be/6s3ufTanUMo

@vbabka @ljs this one goes to crowdstrike and microsoft: https://www.youtube.com/watch?v=lNHRnhOP3hE ;-)

@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.

@ljs That's a very big "if" right there.