Remote
Anderson Nascimento
@andersonc0d3@infosec.exchange
Director and Security Researcher @alleleintel@infosec.exchange
Blog: https://blog.andersonc0d3.io
0 Followers
0 Following
35 Posts
Joined May 28, 2024
RE: https://infosec.exchange/@andersonc0d3/117293431452812266
Registration is officially open for our September 2027 Introduction to Linux Kernel Exploitation training. We are capping this at 10 students. There are only 4 Super Early Bird seats available.
If you have any questions, just contact me!
Introduction to Linux Kernel Exploitation – September 2027
https://allelesecurity.com/introduction-to-linux-kernel-exploitation-september-2027/
Quoting
I'll be offering an Introduction to Linux Kernel Exploitation training in English, to be held online next year (likely September). This will be a whole-month training, totaling 48 hours split across 12 sessions. We will have live classes with me, and the sessions will be recorded and provided to students within 24 hours for those who can't join live. The classes will happen on Monday, Wednesday, and Thursday from 07:00 PM to 11:00 PM (GMT-3), meaning 4 hours of class per day.
The training is for people interested in getting started in Linux kernel exploitation. We will cover the fundamentals: computer architecture, paging and segmentation, C programming, assembly, the Linux ecosystem, and development/APIs, and then how to exploit vulnerabilities and bypass mitigations (SMEP, SMAP, and KASLR).
Besides the training, we provide support for students as soon as they enroll. We have an exclusive mailing list where I share a lot of content—usually much more detailed than what I share here. The mailing list is also used to help better prepare those with less experience several months before the training happens.
Even though the training is focused on Linux kernel exploitation, I believe it's interesting even for those not looking to work directly in research. I talk about many related topics, from system performance and development to my 10+ years of experience in security research, malware/rootkits in general, and more.
The class will be limited to 10 seats, as this will be my first time teaching it in English. I'll be pleased to help as many people as possible not just learn more, but truly grow and reach the next level in their careers.
Would you be interested? If so, reply here, send a DM, or contact us through our website:
http://allelesecurity.com/contact
Open quoted postOpen post
I'll be offering an Introduction to Linux Kernel Exploitation training in English, to be held online next year (likely September). This will be a whole-month training, totaling 48 hours split across 12 sessions. We will have live classes with me, and the sessions will be recorded and provided to students within 24 hours for those who can't join live. The classes will happen on Monday, Wednesday, and Thursday from 07:00 PM to 11:00 PM (GMT-3), meaning 4 hours of class per day.
The training is for people interested in getting started in Linux kernel exploitation. We will cover the fundamentals: computer architecture, paging and segmentation, C programming, assembly, the Linux ecosystem, and development/APIs, and then how to exploit vulnerabilities and bypass mitigations (SMEP, SMAP, and KASLR).
Besides the training, we provide support for students as soon as they enroll. We have an exclusive mailing list where I share a lot of content—usually much more detailed than what I share here. The mailing list is also used to help better prepare those with less experience several months before the training happens.
Even though the training is focused on Linux kernel exploitation, I believe it's interesting even for those not looking to work directly in research. I talk about many related topics, from system performance and development to my 10+ years of experience in security research, malware/rootkits in general, and more.
The class will be limited to 10 seats, as this will be my first time teaching it in English. I'll be pleased to help as many people as possible not just learn more, but truly grow and reach the next level in their careers.
Would you be interested? If so, reply here, send a DM, or contact us through our website:
http://allelesecurity.com/contact
1
0
0
1
Open post
Linux kernel is adding support for a new mechanism to validate lock usage during compile-time. It depends on a new Clang feature called Thread Safety Analysis.
"Implement compiler-driven static analysis locking context checking, using the upcoming Clang 22 compiler's context analysis features."
Documentation/dev-tools/context-analysis.rst
https://github.com/torvalds/linux/blob/master/Documentation/dev-tools/context-analysis.rst
Thread Safety Analysis
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
12
0
7
0
Open post
1
0
0
0
Open post
Replying to
Modify pages_map() to support mapping uncommitted virtual memory.
https://github.com/jemalloc/jemalloc/commit/c2f970c32b527660a33fa513a76d913c812dcf7c
work around heuristic overcommit causing fork failure + improve behaviour with no overcommit
#193
https://github.com/jemalloc/jemalloc/issues/193
0
0
0
0
Open post
Open post
Replying to
Claude couldn't write an exploit after a few hours of work.
0
0
0
0
Open post
Replying to
Defeating Transient Execution Attacks by Limiting Secret Reachability through REGISTER HIDING and SHADOWCFI
https://people.csail.mit.edu/mengjia/data/2026.SP.RegisterHiding.pdf
0
1
0
0
Open post
Replying to
Safe RET Interrupt Vulnerability
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7061.html
0
0
0
0
Open post
Red Hat is working on a capability for virtual machine guests (tenants) to provide their own firmware (UEFI).
This is interesting for measured boot (attestation), implementing per-guest features/configurations, and various other use cases. It's known as Bring Your Own Firmware (BYOF).
Introducing FUKI, guest firmware in a UKI for confidential cloud deployments (2025)
https://archive.fosdem.org/2025/schedule/event/fosdem-2025-4661-introducing-fuki-guest-firmware-in-a-uki-for-confidential-cloud-deployments/
Empowering confidential VMs in the cloud to use their own firmware upon instantiation. (2024)
https://people.redhat.com/~anisinha/BYOF-KVMForum2024.pdf
Additionally, there is a technical challenge regarding resetting certain confidential guests. Because their CPU register states and memory regions are encrypted and inaccessible to the host, the hypervisor cannot execute a standard, hardware-assisted reset, which previously caused these confidential guests to terminate upon a reboot attempt.
The author explains the problem and the two approaches to address it in the blog post below:
Confidential guest reset on QEMU hypervisor: Design choices and approach
https://www.redhat.com/en/blog/confidential-guest-reset-qemu-hypervisor-design-choices-and-approach
0
0
0
0
Open post
FreeBSD has added the pdopenpid() system call. It is the FreeBSD equivalent of pidfd_open() on Linux.
kern: add pdopenpid(2)
https://github.com/freebsd/freebsd-src/commit/5c32aa785184bb1e646b0b4c73d3c5fd9a6b8951
pdfork.2: document pdopenpid(2)
https://github.com/freebsd/freebsd-src/commit/3e8b68c26e2b108dac96517ef8fd26fe7dce5bcd
sys: add pdopenpid(2)
https://reviews.freebsd.org/D57124
0
0
0
0
Open post
Debugging with CHERI
CHERI is designed to improve the security of both existing and future software.
https://freebsdfoundation.org/our-work/journal/browser-based-edition/improving-software-quality/debugging-with-cheri-2/
0
0
0
0
Open post
perf/x86/amd/brs: Fix kernel address leakage
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47915e855fb38b42133e31ba917d99565f862154
perf/x86/amd/lbr: Fix kernel address leakage
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a892294b83f541115c94b0bb637f39bef187657
0
0
0
1
Open post
Second server that I am having issues with the fan. The first one wasn't under warranty and I didn't have support from the vendor to fix it. I ended up damaging it when trying to understand what was going on and how to fix it.
This one now is new and it's already the third fan with issues. In the first two occurrences with this server, the vendor sent me new fans.
I am intrigued that two different servers ended up having the same issues. The consequence of the issue is that the fans operate at higher RPMs, making a very loud noise. It shouldn't be dust. A server's fan doesn't support home-level dust?! It's also not connected to the power line directly. It's powered by a sinusoidal no-break. It's a minor problem that causes a lot of headache. The error is shown below.
2026-07-13 14:18:01 2054 FAN0001 Fan 2 RPM is less than the lower critical threshold.
0
0
0
0
Open post
I used FreeBSD Boot Environment (BE) for the first time and it's awesome!
It allows me to build a kernel and world (userspace), switch to them and in case of failure, revert everything back with just a command. Check out the articles below for more information about it.
Managing Boot Environments
https://klarasystems.com/articles/managing-boot-environments/
FreeBSD Boot Environments on ZFS
https://srobb.net/fbsdbe.html
ZFS Boot Environment Introduction
https://wiki.freebsd.org/unitrunker/BE
Boot Environments
https://wiki.freebsd.org/BootEnvironments
ZFS Boot Environments Revolutions
https://vermaden.wordpress.com/2022/03/14/zfs-boot-environments-revolutions/
0
0
0
0
Open post
RE: https://infosec.exchange/@andersonc0d3/116903287835170560
The fixes in the quoted post are a great example of LLM-assisted development. One issue was fixed, and Sashiko automatically noticed that another component had the same issue.
This has likely happened several times in Linux kernel history. I remember one case I posted about years ago — it took 301 days for the fix in the other component to land upstream.
In this era of LLM-assisted development, the similar issue was spotted in just 17 seconds.
"An example I often mention is the issues below. The three mechanisms (message queues, semaphores, and shared memory) of the IPC subsystem in the Linux kernel share code. Knowing this, if there's a vulnerability affecting one mechanism, it’s worth checking if it also affects the other mechanisms. They fixed a vulnerability in the semaphore mechanism but forgot the message queues and shared memory mechanisms. Analyzing public fixed vulnerabilities can help you learn about the inner details of the affected subsystem and sometimes even lead to new vulnerabilities being discovered."
ipc/sem.c: fully initialize sem_array before making it visible
https://github.com/torvalds/linux/commit/e8577d1f0329d4842e8302e289fb2c22156abef4
Initialize msg/shm IPC objects before doing ipc_addid()
https://github.com/torvalds/linux/commit/b9a532277938798b53178d5a66af6e2915cb27cf
Open quoted post
Quoting
perf/x86/amd/brs: Fix kernel address leakage
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47915e855fb38b42133e31ba917d99565f862154
perf/x86/amd/lbr: Fix kernel address leakage
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a892294b83f541115c94b0bb637f39bef187657
Open quoted post 0
0
0
0
Open post
Dnsmasq DNS Remote Heap Buffer Overflow
https://blog.exodusintel.com/2026/07/20/dnsmasq-dns-remote-heap-buffer-overflow/
0
0
0
0
Open post
The GNU C Library version 2.44 is now available
https://sourceware.org/pipermail/libc-alpha/2026-July/179159.html
0
0
0
0
Open post
Claude referenced an exploitation technique by the name of the researcher who wrote a public paper about it. The thing is that I had used the technique a few years before that work appeared. I didn't discover it, though. A co-worker shared it with me at the time, and he had learned it from a public work. It was there in a public work, but just a few people seem to have noticed it.
That's not a problem, and today I am totally fine with it. I believe this is part of becoming mature intellectually.
I've spent a great amount of time in the past reading about science and its history, and in the past I bothered when the credit went to the second and third discoverer/researcher. It has happened thousands and thousands of times. However, as I am getting older and more experienced about life, I accepted that this is uncontrollable and it's just how things work.
0
1
0
0
Open post
RE: https://infosec.exchange/@andersonc0d3/116980936217755939
This was fixed after I reported a way to bypass pointer guard (PTR_MANGLE) in glibc. I had known about and taught the technique in my binary exploitation classes for a few years (since ~2020/2021), but I wasn't sure whether the glibc team was aware of it.
After the report, a developer mentioned several related issues and started working on the fixes. Besides the technique I reported, I didn't know about the others — I don't focus on binary exploitation beyond my training classes. I was surprised by how many issues there were in glibc that allowed mitigation bypasses. The fix for one of those issues landed in glibc 2.44 today.
My report:
Mitigating __pointer_chk_guard_local exposure and pointer mangling in ld.so
https://sourceware.org/pipermail/libc-alpha/2026-May/177729.html
0
0
0
0
Open post
RE: https://infosec.exchange/@andersonc0d3/116574727959286021
Playing with canaries
Looking at SSP over several architectures.
https://www.elttam.com/blog/playing-with-canaries
0
0
0
0
Open post
Release 2.47 of the GNU Binutils is now available
https://inbox.sourceware.org/binutils/87o6fty5pz.fsf@redhat.com/
0
0
0
0
Open post
Initial discussion of what became the perf subsystem in the Linux kernel.
[patch 0/3] [Announcement] Performance Counters for Linux
https://lore.kernel.org/all/20081204225345.654705757@linutronix.de/
0
0
0
0
Open post
amd64: do not allow to set reserved bits in MXCSR for ptrace(PT_SETFPREGS)
https://github.com/freebsd/freebsd-src/commit/cef05c5a62ba63eda222eed083972bfaa1449ac2
0
0
0
0
Open post
AT_SECURE programs may load attacker-controlled code via $ORIGIN
AT_SECURE program buffer overflow via $ORIGIN processing
https://sourceware.org/pipermail/libc-announce/2026/000064.html
0
0
0
0
Open post
AMD EPYC Rome Application Performance on vSphere Series: Part 1 – SQL Server 2019
https://blogs.vmware.com/cloud-foundation/2020/04/23/amd-epyc-rome-application-performance-on-vsphere-series-part-1-sql-server-2019/
AMD 2nd Gen EPYC (Rome) Application Performance on vSphere Series: Part 2 – VMmark
https://blogs.vmware.com/cloud-foundation/2020/05/27/app-perf-vmware-vsphere-amd-epyc-rome/
0
0
0
1
Open post
RE: https://infosec.exchange/@andersonc0d3/117325659239046952
I shared this because it was with this article series that I learned about LLC (CCX) as a NUMA domain on AMD processors. I have finally found the time and incentive to learn more about modern processors and systems. There are many acronyms and details that I didn't know about.
In fact, I came across that term/feature in an official tuning guide from AMD for Red Hat Enterprise Linux, and when searching about it, I bumped into these articles from VMware.
Intel also has a similar feature that is called Sub-NUMA-Clustering (SNC).
Impact of sub-numa-clustering (SNC) on LLC access
https://stackoverflow.com/questions/74511855/impact-of-sub-numa-clustering-snc-on-llc-access
It seems some people get performance benefits by enabling that feature.
Best CPU performance settings for HP DL325/AMD EPYC servers?
https://xcp-ng.org/forum/topic/4421/best-cpu-performance-settings-for-hp-dl325-amd-epyc-servers
Open quoted post
Quoting
AMD EPYC Rome Application Performance on vSphere Series: Part 1 – SQL Server 2019
https://blogs.vmware.com/cloud-foundation/2020/04/23/amd-epyc-rome-application-performance-on-vsphere-series-part-1-sql-server-2019/
AMD 2nd Gen EPYC (Rome) Application Performance on vSphere Series: Part 2 – VMmark
https://blogs.vmware.com/cloud-foundation/2020/05/27/app-perf-vmware-vsphere-amd-epyc-rome/
Open quoted post 0
0
0
0
Open post
Replying to
@gzobra@infosec.exchange Yes, but I'd prefer not to name names to avoid getting involved in controversies.
0
1
0
0
Open post
Replying to
@gzobra@infosec.exchange If you're still interested, feel free to reach out to me directly and I can share the details. You can find me on other social media and DM me there.
0
0
0
0
Open post
Replying to
@buherator@infosec.place I almost skipped it after reading some bits because of the way it's written, but it's a cool post. I'll be sharing it with the people who took my binary exploitation training.
0
0
0
0
