From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0512931355C for ; Thu, 2 Apr 2026 11:02:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775127761; cv=none; b=DD+vmeyBO5gBZfOsoyz6Y5MDAXkZTYBhycAy+hdjU/qU4iSUt80q/EOzLsIzFfJXpzb/YE/+/8mkhawuRW9iniYU9wxysS8E38sR7SHX/CnrO9W/Ks+M1L10o/aMHLwT2Y5paKJdARkauQNHRybMIg2ajKsBYXbteQmQ0kx/Fcg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775127761; c=relaxed/simple; bh=TV/v07Ls87GlweaK/zjI1EApvWQBaTcyje+xlVKZI54=; h=Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type; b=FzA6hSd022SO1tfkP+70lWBudUEc7CO7wmqc41qIVk9DrKEHLqWfKRagZgh/62zpDRyWyZO1fu8CEpTUJti1P/TxFjkKOfEsgkJY1P9+Xw5vpLYIG+2Kt7laGLKsI3kOHxc9bJjr4opOCKPgw9OKszMQgUUFN5zmcq+xAD+sNik= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=DCIHWI3M; arc=none smtp.client-ip=209.85.210.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DCIHWI3M" Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-82cebbdbdccso357260b3a.1 for ; Thu, 02 Apr 2026 04:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775127759; x=1775732559; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:date:subject:cc:to:from :message-id:from:to:cc:subject:date:message-id:reply-to; bh=bD6hxrjoL3zY29yjIFUvmOGd5Vvb3HUAvN0+0dLRAkA=; b=DCIHWI3MyqFEnDCnDYlyGh+jpboaLW6UOdFqSoGliGTMTQ6TMK+8Ys48lgyrOCihH1 ilCg3cmg6YDAjkoKOm3NP9y924mQM6Yd/Kd2wvromT46pTJAqdSwVpd/2OcFZEhitFNo TDkBajySYUK02BlTMVrBYa2xdIKdkW9mQSrGTEEziEbO7qJwLL3UexSFb+9bdP8KJkPY br6cjcR8oIfXdMMEv6KWVM2kdVy92rupZ6opoZUm+UYVj1AkU6Ria1a2Cf9FUnB/eHq4 M2ASeqf36bDoliMRGVDKUL5ArNCVc2qyRxDBgEPvvUEAyGJSX+4qW5cZVbRTsvWHFVFK v7YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775127759; x=1775732559; h=content-transfer-encoding:mime-version:date:subject:cc:to:from :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bD6hxrjoL3zY29yjIFUvmOGd5Vvb3HUAvN0+0dLRAkA=; b=I9zZLMO85AczXRmaIASxKCBuqA7YEKFs7XzMBVxDP4dYBgMpJKpM5tWmC5Xo9o5WBj d4tlspJ3TYO+HKFYVt5cCZ5tkgyikDiLLYFQ7+Uv0F/3+y9U9wmUZa7WtVJYh6Vnp1UN /MV2NuoRbYZMKkuncf2NQr7Qi4WLPWJWWDivGu5XyZRNZVFPFJ2ni3imcniUvf6fzWmd ul8YeMlG2Q92HOTGpn10Wax5NMG4AK1qHatXc4FmI9f/KLaVtiAer8wvp4B6CEhjeRRT WJW/g4wKfGW87LqbZKx4FPL69KUVrT/kLHcnPaNsZwnGXMSP8wsos5DUkuVxxS5eF/Mv k4yw== X-Gm-Message-State: AOJu0YxO3rayaladN2oHeNjh50Ay7Vx3Ayht7qDRJQkNgzj7Hzyhaa3D XEYEwBbvnwJtuRl5WwfhHwKcn5ybuxp07Z4C/aRzXssvjeqqPRCygztb X-Gm-Gg: ATEYQzy9URHmqQhKSHsdByul3kr15ZUTsrSFMoNfMsb8+RfhvuiaR0oTbn33VkvRA+W wavvdf/bPpETRIXLukNO5CpBTdjWoF3k9JvJTYJdu9BlDyaC/pQFH773z7ScOVhPu/OmrB9QEEJ jIS8U7SxRIrZBP7zfySRaCZRLI0OeP4NevL+AE4dWz6OCCYUQppr3rqXo/COokck5qc1JI8NQOH k2lpnclOINszR0yENr10xYwnA7LYgsTSNFom98DvC01N0c3MLGeT40PiMpIHBBWk7n4fUDrSyrk b32qKvF2Y62K00JTV2fyJjwzf2Bp4jVRlzOhi8rSl7J2DV9d4b6Mf5LrL9yGDnIQ3EUZnc5ExXs BVdpIJ0G5tg4EGhSqgmvorepjEESYfz/FBwQPaLDSd6JrjWHO6F0rgLd2Y71eQrXsQmceh0DVaU tYMcMi6dF7BLI9T7DXqbk= X-Received: by 2002:a05:6a00:1ad3:b0:82a:6e4b:5b4d with SMTP id d2e1a72fcca58-82d0035bd98mr1788145b3a.23.1775127759155; Thu, 02 Apr 2026 04:02:39 -0700 (PDT) Received: from localhost ([137.132.22.254]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82cf9b3baffsm2812910b3a.14.2026.04.02.04.02.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2026 04:02:38 -0700 (PDT) Message-ID: <69ce4cce.050a0220.83ffb.e251@mx.google.com> From: ven0mfuzzer To: Viacheslav Dubeyko , Ilya Dryomov , Alex Markuze Cc: linux-kernel@vger.kernel.org, ceph-devel@vger.kernel.org Subject: [BUG] OrangeFS Kernel Client Use-After-Free in atomic_dec_and_lock Date: Thu, 02 Apr 2026 19:02:37 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: KernelStackFuzz send_email.sh OrangeFS Kernel Client Use-After-Free in atomic_dec_and_lock 1. Vulnerability Title Linux Kernel OrangeFS/Ceph Client Use-After-Free Write in atomic_dec_and_lock via Corrupted Server Response (ceph_put_snapid_map) 2. High-Level Overview A use-after-free write vulnerability exists in the Linux kernel's Ceph filesystem layer, triggered via the OrangeFS kernel client. When a corrupted OrangeFS/Ceph server response causes inode state to become inconsistent, the `snapid_map` object is freed prematurely. A subsequent directory operation (`mkdir` → `lookup` → `d_invalidate` → `iput` → `evict`) calls `ceph_evict_inode()` → `ceph_put_snapid_map()`, which performs an `atomic_dec_and_lock()` on the already-freed `snapid_map` object — a 4-byte use-after-free write. This is a moderate-severity vulnerability: the corrupted response may cause premature freeing of the snapid_map object, potentially leading to kernel memory corruption or denial of service when subsequently accessed. This vulnerability was discovered using ven0mfuzzer, our custom-designed MITM-based network filesystem fuzzer developed by our team. Following the common syzkaller practice, we submit the kernel crash trace as the primary reproduction artifact. 3. Affected Product and Version Information Product: Linux Kernel (upstream mainline) Affected Component: `fs/ceph/snap.c` — `ceph_put_snapid_map()`; `fs/orangefs/` — OrangeFS kernel client triggering the code path Tested Version (confirmed vulnerable) - Linux kernel 6.19.0 (mainline, commit `44331bd6a610`, gcc 11.4.0, built with KASAN + LOCKDEP + UBSAN + KFENCE) Affected Version Range All kernels with `CONFIG_ORANGEFS_FS=y` and `CONFIG_CEPH_FS=y` are believed affected. Affected Environments | Environment | Notes | | --- | --- | | HPC clusters using OrangeFS | Primary deployment target for OrangeFS | | Research storage systems | Academic/lab environments with OrangeFS parallel storage | | Any Linux system with CONFIG_ORANGEFS_FS | Not common in desktop distros; mainly HPC/research | 4. Root Cause Analysis 4.a. Detailed Description The OrangeFS kernel client shares infrastructure with the Ceph filesystem, including inode management and snapid mapping. When a MITM-corrupted server response causes the kernel to build an inode with inconsistent snapshot state, the `snapid_map` reference count becomes mismanaged. The corrupted response leads to a premature free of the `snapid_map` object. When a subsequent directory operation triggers inode eviction via `ceph_evict_inode()`, it calls `ceph_put_snapid_map()` which performs `atomic_dec_and_lock()` on the already-freed memory — a 4-byte write to freed slab memory. The fundamental issue is that the OrangeFS/Ceph client does not validate server-supplied inode attributes before using them to initialize internal kernel structures. Corrupted attributes lead to refcount mismanagement and eventually use-after-free. 4.b. Code Flow --- [Initial corruption — premature free] pvfs2-client-core → /dev/pvfs2-req → orangefs_inode_getattr() → [corrupted inode attributes from server] → [snapid_map refcount becomes inconsistent] → [premature kfree of snapid_map] [Trigger path — UAF write] mkdir(2) → lookup_one_qstr_excl() → lookup_dcache() → d_invalidate() → shrink_dcache_tree() → shrink_dentry_list() → __dentry_kill() → dentry_unlink_inode() → iput() → evict() → ceph_evict_inode() → ceph_put_snapid_map() → atomic_dec_and_lock() ← UAF WRITE (4 bytes) --- 4.c. Crash Trace This vulnerability was discovered by ven0mfuzzer. The following kernel trace is submitted following syzkaller's common practice of providing the raw crash trace as the primary reproduction evidence: --- BUG: KASAN: slab-use-after-free in atomic_dec_and_lock+0x24/0x120 Write of size 4 at addr ffff888109374a68 by task mkdir/905 CPU: 1 UID: 0 PID: 905 Comm: mkdir Tainted: G W 6.19.0-g44331bd6a610-dirty #9 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x660 kasan_report+0xe0/0x110 kasan_check_range+0x105/0x1b0 atomic_dec_and_lock+0x24/0x120 ceph_put_snapid_map+0x3f/0x260 ceph_evict_inode+0x2e8/0x890 evict+0x3c2/0xad0 iput+0x79a/0xd30 dentry_unlink_inode+0x29c/0x480 __dentry_kill+0x1d0/0x600 shrink_dentry_list+0x134/0x680 shrink_dcache_tree+0x100/0x5e0 d_invalidate+0x13a/0x290 lookup_dcache+0x13c/0x170 lookup_one_qstr_excl+0x2a/0x250 --- Reproduced 1 time. 4.d. Suggested Fix Add refcount validation in the inode initialization path when processing server-supplied attributes, and validate `snapid_map` is not already freed before decrementing: --- / In ceph_put_snapid_map(), add a refcount sanity check / void ceph_put_snapid_map(struct ceph_snapid_map *sm) { if (!sm) return; + if (WARN_ON(refcount_read(&sm->ref) == 0)) + return; if (atomic_dec_and_lock(&sm->ref, &snap_empty_lock)) { ... } } --- The deeper fix should validate server-supplied inode attributes before using them to initialize internal kernel structures. 5. Discovery Method and Reproduction 5.a. Discovery This vulnerability was discovered using ven0mfuzzer, a custom-designed MITM-based network filesystem fuzzer developed by our team. The fuzzer operates by positioning an AF_PACKET/TCP transparent proxy between a Linux kernel filesystem client (VM-A) and its server (VM-B), then mutating network protocol messages in-flight. Following the common syzkaller practice, we submit the kernel crash trace as the primary reproduction artifact. 5.b. Reproduction Setup --- VM-A (pvfs2 client + pvfs2-client-core) ──BMI/TCP port 3334──► Host (MITM proxy) ──TCP──► VM-B (pvfs2-server) --- - Kernel: Linux 6.19.0 (commit `44331bd6a610`) with KASAN + LOCKDEP + UBSAN + KFENCE enabled - Server: OrangeFS 2.10.0 (compiled with AddressSanitizer) - Trigger: MITM mutation of server responses during directory operations causes inode corruption → premature snapid_map free → UAF on subsequent operation - No standalone PoC — the crash trace above serves as the reproduction artifact --- Reported-by: ven0mfuzzer Link: https://github.com/KernelStackFuzz/KernelStackFuzz