<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Moe's VR blog</title><link>https://mohandacherir.github.io/Qdiv7/</link><description>Recent content on Moe's VR blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 25 May 2026 18:48:03 +0200</lastBuildDate><atom:link href="https://mohandacherir.github.io/Qdiv7/index.xml" rel="self" type="application/rss+xml"/><item><title>Qualcomm DSP - Userland Allocator</title><link>https://mohandacherir.github.io/Qdiv7/posts/qurt-allocator/</link><pubDate>Mon, 25 May 2026 18:48:03 +0200</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/qurt-allocator/</guid><description>&lt;p>In this post, i talk about some QuRT internals and about the userland allocator. I worked with the online available Qualcomm&amp;rsquo;s SDK top extract the binaries that implement the allocator&amp;rsquo;s logic.
Most of this logic is found in a file called &lt;code>libc.a&lt;/code> which is an archive that stores &lt;code>.o&lt;/code> binaries like &lt;code>malloc.o&lt;/code>, &lt;code>free.o&lt;/code>&amp;hellip;etc. A quick way to extract these binaries, after downloading the SDK, is:&lt;/p></description></item><item><title>Qualcomm SoC Internals Basics</title><link>https://mohandacherir.github.io/Qdiv7/posts/qualcomm-soc/</link><pubDate>Sun, 17 May 2026 20:16:14 +0200</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/qualcomm-soc/</guid><description>&lt;p>Starting my journey in Mobile Vendor Chips internals &amp;amp; VR, i chose Qualcomm SoC since it is a very well known and a dominant brand in the phone space, and of course, a cherished target among exploit developers in many angles. However, it has a complex architecture and massive codebase; if we take for example the &lt;code>Snapdragon&lt;/code> SoCs, they have: a CPU, Andreno GPU, many DSPs, AI accelerators(NPU), sensors, video processors&amp;hellip;etc and each one of these has its own microprocessor, firmware and Operating System; so, even to start out, one should at least have a big picture before blindly diving into one specific thing; hence my goal is to establish some foundation.&lt;/p></description></item><item><title>Scudo Allocator - Internals</title><link>https://mohandacherir.github.io/Qdiv7/posts/scudo-allocator/</link><pubDate>Sun, 10 May 2026 16:56:47 +0200</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/scudo-allocator/</guid><description>&lt;p>Everybody knows that iOS pwn is (real) hard for userland(and kernel too obviously); but folks, you should know that even Android is catching up now, so don&amp;rsquo;t worry, you can keep your Pixel 18 Pro Max ;-) LOLL&lt;/p></description></item><item><title>Nvidia Drivers Internals - Part 0</title><link>https://mohandacherir.github.io/Qdiv7/posts/nvidia-internals/</link><pubDate>Thu, 07 May 2026 19:08:31 +0200</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/nvidia-internals/</guid><description>&lt;p>I recently wrote this article for my company; this is an introductory post and hope to write more on this in the near future:&lt;/p>
&lt;p>&lt;a href="https://fuzzinglabs.com/exploring-nvidia-linux-drivers-internals-basics-ioctls/">https://fuzzinglabs.com/exploring-nvidia-linux-drivers-internals-basics-ioctls/&lt;/a>&lt;/p></description></item><item><title>Unix GC Remastered</title><link>https://mohandacherir.github.io/Qdiv7/posts/unix_new_gc/</link><pubDate>Sun, 19 Apr 2026 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/unix_new_gc/</guid><description>&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>The AF_UNIX garbage collector is an interesting piece of the kernel. It exists because sockets can be sent with SCM_RIGHTS but they can become unreachable from user-space while still being kept alive by the kernel, which is not memory efficient; in this situation, the garbage collector intervenes to free them. Not long ago, the subsystem was rewritten from scratch on top of a graph/Strongly-Connected-Components model; but it is still bug prone.
This post walks the rewrite end-to-end, and discusses a Use-After-Free bug.&lt;/p></description></item><item><title>CVE-2026-31419: Use-After-Free in the Linux Bonding Driver</title><link>https://mohandacherir.github.io/Qdiv7/posts/cve-2026-31419/</link><pubDate>Wed, 15 Apr 2026 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/cve-2026-31419/</guid><description>&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>Linux offers a way to synchronize multiple network interfaces, physical or virtual, and make them run a single logical NIC. The bonding driver handles of all that work.
It is present in all major distros and this bug is exploitable in the ones that allow usernamespaces for unprivileged users like in RedHat or Fedora; that is, it&amp;rsquo;s reachable from any code path that can send packets out of the bonding device.&lt;/p></description></item><item><title>CVE-2024-0582, or Easy Kernel Exploitation</title><link>https://mohandacherir.github.io/Qdiv7/posts/n-day-exploit-cve-2024/</link><pubDate>Wed, 18 Mar 2026 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/n-day-exploit-cve-2024/</guid><description>&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>&lt;strong>io_uring&lt;/strong> has been a heavily targeted subsystem in the Linux kernel — at one point it constituted 60% of kCTF entries (&lt;a href="https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html">source&lt;/a>). As with most newly introduced features, io_uring — since its introduction in 2019 — has been very bug-prone.&lt;/p></description></item><item><title>Notes On RCU</title><link>https://mohandacherir.github.io/Qdiv7/posts/notes_on_rcu/</link><pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/notes_on_rcu/</guid><description>&lt;p>RCU is a mechanism in the Linux kernel for concurrency that is lock-free, wait-free (for readers) and that allows concurrent readers and a single updater.
RCU is made up of three fundamental mechanisms, one for &lt;strong>insertion&lt;/strong>, the other for &lt;strong>deletion&lt;/strong>, and the third being used to allow readers to tolerate &lt;strong>concurrent insertions and deletions&lt;/strong>. These mechanisms are described in the following sections, which focus on applying RCU to linked lists.&lt;/p></description></item><item><title>Notes on io_uring bugs &amp; exploitation</title><link>https://mohandacherir.github.io/Qdiv7/posts/io_uring_exploitation/</link><pubDate>Tue, 20 Jan 2026 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/io_uring_exploitation/</guid><description>&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>&lt;code>io_uring&lt;/code> is one of the most ambitious kernel interfaces added in recent years: a shared-memory asynchronous I/O engine designed to avoid the syscall-heavy overhead of traditional &lt;code>read&lt;/code>, &lt;code>write&lt;/code>, and networking paths. That performance-oriented design also makes it unusually interesting from a security perspective, because the subsystem is full of long-lived shared state, lifetime-sensitive objects, and fast paths that interact closely with core kernel memory-management code.&lt;/p></description></item><item><title>Notes on refcounting and Unix Garbage Collector in the Linux Kernel</title><link>https://mohandacherir.github.io/Qdiv7/posts/refcounting-linux-kernel/</link><pubDate>Tue, 23 Dec 2025 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/refcounting-linux-kernel/</guid><description>&lt;p>As a means of studying and getting to know more about the linux kernel, especially exploitation(LPE &amp;amp; RCE), i tried to make notes and go as far as i can in reviewing the &lt;strong>unix garbage&lt;/strong>, or &lt;strong>GC&lt;/strong>, collector, the &lt;strong>io_uring&lt;/strong> subsystem, and some CVEs that showcase all of these. I am currently working on an N-day LPE for CVE-2022-2602 LPE to make it work with &lt;strong>FUSE&lt;/strong> technique.&lt;/p></description></item><item><title>Notes on Linux Internals: The Slab Allocator</title><link>https://mohandacherir.github.io/Qdiv7/posts/notes-on-linux-internals-the-slab-allocator/</link><pubDate>Sat, 06 Sep 2025 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/notes-on-linux-internals-the-slab-allocator/</guid><description>&lt;h2 id="introduction">Introduction&lt;/h2>
&lt;p>This post is some of my early notes on the SLUB allocator.&lt;/p>
&lt;p>The kernel heap allocator is an important component responsible for satisfying allocation/de-allocation requests coming from different sources like device drivers, usermode processes, filesystems, etc. These notes discuss only &lt;code>kmalloc&lt;/code> and &lt;code>kmem_cache_alloc*&lt;/code>, but there are three main memory allocators used by the kernel:&lt;/p></description></item><item><title>Faulted RSA Signature</title><link>https://mohandacherir.github.io/Qdiv7/posts/faulted-rsa-signature/</link><pubDate>Sun, 15 Dec 2024 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/faulted-rsa-signature/</guid><description>&lt;h1 id="faulted-rsa-signature-attack">Faulted RSA signature attack&lt;/h1>
&lt;p>Le challenge commence par &amp;ldquo;Nous savons que les signatures ont été générées par un service en Go 1.5.1 sur une architecture
32 bits&amp;rdquo;.&lt;br>
Après avoir médité sur cette ligne, quelques recherches sur la version 1.5.1 de Go ont révélé que ce
service est susceptible à des erreurs dans le processus d’exponentiation.&lt;br>
Ensuite, il nous est donné dix signatures, une clé publique RSA et un message chiffré avec la clé privée correspondante qu&amp;rsquo;on ne
connait pas.&lt;/p></description></item><item><title>HTB Permx</title><link>https://mohandacherir.github.io/Qdiv7/posts/htb-permx/</link><pubDate>Sun, 15 Dec 2024 00:00:00 +0000</pubDate><guid>https://mohandacherir.github.io/Qdiv7/posts/htb-permx/</guid><description>&lt;h1 id="permx-walkthrough">Permx walkthrough&lt;/h1>
&lt;p>&lt;strong>OS&lt;/strong>: Linux, &lt;strong>Difficulty&lt;/strong>: Easy&lt;/p>
&lt;h2 id="enumeration">Enumeration&lt;/h2>
&lt;p>Ports scan: &lt;code>nmap -p- -sCV 10.10.11.23&lt;/code>&lt;/p>
&lt;pre tabindex="0">&lt;code>PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
| 256 e2:5c:5d:8c:47:3e:d8:72:f7:b4:80:03:49:86:6d:ef (ECDSA)
|_ 256 1f:41:02:8e:6b:17:18:9c:a0:ac:54:23:e9:71:30:17 (ED25519)
80/tcp open http Apache httpd 2.4.52
|_http-title: Did not follow redirect to fer
|_http-server-header: Apache/2.4.52 (Ubuntu)
Service Info: Host: 127.0.1.1; OS: Linux; CPE: cpe:/o:linux:linux_kernel
&lt;/code>&lt;/pre>&lt;p>There&amp;rsquo;s no available exploit for this version of Openssh, and passwordless connexions are not possible.&lt;br>
The http server redirects to &lt;code>permx.htb/&lt;/code>, so i added &lt;code>10.10.11.23 permx.htb&lt;/code> to &lt;code>/etc/hosts&lt;/code>: &lt;code> echo &amp;quot;10.10.11.23 permx.htb&amp;quot; | sudo tee -a /etc/hosts&amp;quot;&lt;/code>.&lt;/p></description></item></channel></rss>