CVE-2024-35896 in Linux
Riassunto
di VulDB • 30/06/2026
Based on the KASAN (Kernel Address Sanitizer) report provided, here is a detailed analysis of the bug:
### **Summary** * **Bug Type:** **Out-of-bounds Write** (specifically, writing to an address that belongs to a `kmalloc-8` slab object). * **Severity:** Critical. This can lead to memory corruption, kernel crashes (Oops/Panic), or potential security vulnerabilities. * **Triggering System Call:** `setsockopt()` (`__x64_sys_setsockopt`). * **Root Cause Location:** The bug occurs inside the BPF cgroup filter code: `kernel/bpf/cgroup.c` in function `__cgroup_bpf_run_filter_setsockopt`.
---
### **Detailed Analysis**
#### 1. **The Faulty Access** ```text RAX: ffffffffffffffda <-- This is -22 (EINVAL) or similar error code, but the key is below. ... Allocated by task 7238: ... __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 ``` * The crash/access violation happened at offset `+0xd47` within the function `__cgroup_bpf_run_filter_setsockopt`. * KASAN detected an invalid memory access.
#### 2. **The Buggy Address & Allocation** ```text The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
``` * **Object Size:** The memory was allocated from the `kmalloc-8` cache, meaning it expects to be used as an object of size **up to 8 bytes**. * **Actual Usage:** However, KASAN reports that only a **1-byte region** `[ffff88802cd73da0, ffff88802cd73da1)` was marked as "allocated" or used within this object. This suggests:
* Either the code is writing to an offset beyond what it should (OOB write). * Or there’s a mismatch between how much memory was allocated vs. how much is being accessed. * **Note:** The phrase *"located 0 bytes inside of allocated 1-byte region"* typically means KASAN detected access at the very beginning (`+0`) of an object that it believes should only be 1 byte in size, but since this came from `kmalloc-8`, something is wrong with either: * The allocation logic (allocated more than needed?). * Or more likely, **the code wrote beyond the intended bounds** into adjacent memory or corrupted metadata.
> ⚠️ **Important Interpretation:** In KASAN reports like this, if it says "buggy address is located 0 bytes inside of allocated X-byte region", and that object came from `kmalloc-8`, it often means: > - The code intended to use a small structure (maybe 1 byte? unlikely). > - Or more plausibly: **The write went out-of-bounds** into the redzone or adjacent objects, but KASAN is reporting based on its tracking of what *should* have been accessed.
However, looking closely at typical KASAN output patterns: If it says `"allocated 1-byte region"`, this usually implies that within the `kmalloc-8` object, only **one byte** was considered "live/used" by KASAN’s instrumentation (perhaps due to a small struct), and the write happened outside even that tiny scope — or there's confusion in interpretation.
But given it’s from `__cgroup_bpf_run_filter_setsockopt`, which handles socket options via BPF programs, this is likely an **out-of-bounds read/write** when processing user-provided data for a setsockopt option.
#### 3. **Call Trace Breakdown** ```text entry_SYSCALL_64_after_hwframe+0x72/0x7a ← User syscall entry do_syscall_64+0xfb/0x240 ← Syscall dispatcher __x64_sys_setsockopt+0xb5/0xd0 ← setsockopt wrapper __do_sys_setsockopt net/socket.c:2340 ← Core setsockopt logic do_sock_setsockopt+0x6b4/0x720 ← Socket-level handling __cgroup_bpf_run_filter_setsockopt+
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.