Er... missed link for that last post, https://sean.heelan.io/2026/01/18/on-the-coming-industrialisation-of-exploit-generation-with-llms/
The latest edition of the Security Liberation Front is out¹:
People, with #Greenland raising awareness of our massive 24/7 dependence on US clouds for vital services, I made a list of what (government) stuff would break here under US sanctions. It is EXTREMELY depressing. Can I suggest that people also make a list like this one for their own countries? It is getting quite some traction here: https://berthub.eu/articles/posts/dashboard-amerikaanse-afhankelijkheden/
Join us for the kick-off of Pwn2Own Automotive 2026! As always, we begin the event with a random drawing to see the order of attempts for the contest, which starts first thing on Wednesday, January 21. https://youtube.com/live/Dtp-ICE0crw
@cstross Put another way: LLMs have revealed a zero-day exploit in human consciousness and culture: if you can manufacture plausibility at scale, you can bypass all of the accumulated wisdom of centuries of skepticism and critical thinking. Any fact-using profession is potentially vulnerable to this attack.
A former writer for South Park foresaw Trump's takeover of the Kennedy Center and had the foresight to register the domain names trumpkennedycenter dot org and dot com back in August. JFK's niece thanked him for doing so. Of course, the Trump-controlled board now wants their domain name and threatened legal action. His response is brilliant.
There seems to be some misinfo kicking around that France (or Ukraine, depending on who you ask) intentionally fed false information to the US, which was then observed as transmitted to Russia.
Ukrainian sources dispute this heavily: https://unn.ua/en/news/did-ukraine-allegedly-provide-the-us-with-distorted-intelligence-the-gur-rejected-fakes-from-kremlin-bot-farms
Only sources boosting this claim are reporting based on Twitter reports.
If this actually happened, you would never hear about it; this would be one of the most closely guarded counterintelligence secrets around. Stay safe out there kids, and fact check online sources with trusted ones.
RE: https://haunted.computer/@binarygolf/115878068970692998
Last day of BGGP6 today!
The British are to blame for this aren’t they
A glimpse into what a kernel engineer debugs for enterprise customers.
A bank is running a "security" solution that installs kprobes to intercept, among other things, calls to do_execveat_common(), and monitors all the arguments that could have been passed to execveat(). As do_execveat_common() can be triggered not only by userspace, but also by call_usermodehelper_exec(), a kprobe crafted with poor assumptions may result in an erroneous double dereference of what it thinks points to argv**, causing a General Protection Fault.
The kernel is not dumb however. If a GPF is triggered by a kprobe, it is handled gracefully, and nothing happens, and kprobe just returns a safe value. For a GPF to be triggered however, the CPU has to really try to read the wrong memory address first. The address is pretty random each time, meaning it can point to memory regions that are not mapped by kernel, but have some special meaning for a platform.
Enter the platform. It is configured by the hardware vendor in such a way that if an unaligned access to an MMIO region happens, an MCE is generated. And it is not some MCE for a correctable error, but an MCE indicating process context corruption, in other words, it's fatal. So, once it happens, the system dies with a kernel panic.
And this is exactly what the customer experienced. A socket() syscall caused modprobe to be invoked via call_usermodehelper_exec() → do_execveat_common() chain to load the ipv6 module. This triggered a kprobe that dereferenced wrong memory pointer twice provoking a GPF. The kernel began to gracefully handle the GPF, but the platform saw that the second dereference resulted in accessing the MMIO region, and this was an unaligned access, hence the platform threw MCE. And the system died.
It was fun to investigate this and to explain to the customer that three legitimate things in their system being hit together can trigger a crash.
And of course we joked we should have moved the whole case to the networking team, because it's always IPv6.
I recently had to deploy a change to #Debian Code Search to limit the amount of memory used during indexing a single package — because of #Firefox, which now ships as 388_859 files, totaling 1.78 GB! The resulting search index is 2.76 GB. Doing this entire indexing in one go is just too much for typical servers.
So now we flush into intermediate index files and merge them in the end: https://github.com/Debian/dcs/commit/8e76d5b9408cd12cfb6b728c1f1f3a96a9775310
The resulting drop in max heap usage is nicely visible on the graph by now :)
But then I discovered https://github.com/builtbybel/Winslop. A tiny tool helped a lot in disabling all of that crap. Nice and simple and it gave me a feeling of control. Thank you Belim! :)
(Yes, this is a lesson in empathy with the user and pretty much accidentally a metaphor that somehow connects to my employer and their main product. No, I will not take any further questions.
P.S. I would prefer arkenfox as a config system over any kind fork)
2/2