<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Slab on ankit_kdev</title><link>https://ankitkdev.com/tags/slab/</link><description>Recent content in Slab on ankit_kdev</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 04 Feb 2026 16:45:19 +0530</lastBuildDate><atom:link href="https://ankitkdev.com/tags/slab/index.xml" rel="self" type="application/rss+xml"/><item><title>Basics of debugging slab memory corruption via SLUB debug</title><link>https://ankitkdev.com/blog/debug-slub-memory/</link><pubDate>Wed, 04 Feb 2026 16:45:19 +0530</pubDate><guid>https://ankitkdev.com/blog/debug-slub-memory/</guid><description>&lt;h1 id="introduction">Introduction&lt;/h1>
&lt;p>Memory corruption can occur due to various bugs or defects: Uninitialized Memory
Reads (UMR), Use After Free (UAF), Use After Return (UAR), double-free, memory
leakage, or illegal Out Of Bounds (OOB) accesses that attempt to work upon (read/write/
execute) illegal memory regions.&lt;/p>
&lt;p>Since memory is dynamically allocated and freed via the kernel&amp;rsquo;s engine – the
page allocator. This can lead to serious wastage (internal fragmentation) of memory.
To mitigate this, the slab allocator (or slab cache) is layered upon it, serving two
primary tasks – providing fragments of pages efficiently (within the kernel, allocation
requests for small pieces of memory, from a few bytes to a couple of kilobytes), and serving as a cache for commonly used data structures.&lt;/p></description></item></channel></rss>