From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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 9532725EF87 for ; Sun, 19 Apr 2026 21:22:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776633737; cv=none; b=ct5SuXzM/j/k1QaRNR5u9mImDseZkDH+KKYx9Xay7Zng9B9twtGx0IcvMG+Js8+/hFlN5qVEYfZlM2g+e/oDvycMCeZJ2uhqqvZqyqSDdH+Wemxn+CCTmjbu5LEXY5UM6z0vLREQTgdvFh6QjLsgxUKcKK+/T1YodjbrswNlqjE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776633737; c=relaxed/simple; bh=4mgFnDuqjDazkpWQSACMpuF+9o6jWUlghenOuJwyDNM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=WY45UGHUL6n4Sfvz8QZd0Zu0Stf3AZ5AWqDKVMPPyyvZ1gqanv88WhQNu0P0TOBiTISXXRXIi4sho1wq5YX8s2/lySRMFBnrVN0Mt0OyryBVl+UsIVyEryTBVGG+mK+uW4+JyyfoO6HGi0iWHFsCe6ZaQOUex3lvx27nNrcgT7k= 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=BiRyQgcj; arc=none smtp.client-ip=209.85.222.169 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="BiRyQgcj" Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-8d68bcf50fdso294368885a.2 for ; Sun, 19 Apr 2026 14:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776633734; x=1777238534; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=qliX1CpRzcqySHVjBmsdzyegBGfy3s8Af3FF3IEJPas=; b=BiRyQgcjrt6Ok4yqnPJexgS4v0aK7KbO+dTi757V1yJOXJA90KPzeOZXMSlBnoW5TR /a4+iJNmDxH2lXVjM1abh408IMR/HywLKYJMDfcoIZYe87kGyT4IOOsRt9W5QLrgmGcN 4YcOLN77KgNLHVSzbEHe1wrM9L/hqn9Edi1ex1IG7/G7EGKSP3yxQKfnTUCLPh29ZDaI uctsBFnIliKDbEfRLa1XtuRlViEUT83pEGGvD0O1ia04+xOqjKL84XP5XhW4pwKO2HD/ Ml7jzqNk0qPCDJ21srpMVzF1kUMrjdShB+sdOcZL1IS0dHp4sCCoDxIJhliIgBUX93ve 7mwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776633734; x=1777238534; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qliX1CpRzcqySHVjBmsdzyegBGfy3s8Af3FF3IEJPas=; b=YQmsd+TEa3+bTmmNz3Mw95bblpWQqM0s+XG7ekK0YxqNfi8AT0IJN0eLxH83aVVxY5 atszSZ3e/wgGtyaY7YPxG3dn0kHEWW2gsGVWV2WqJ3yjYtARq0p2MuRtnBOtHFMap4/g JNoddBKfduFH0bUXMn+BMxbcbvi5a+rUZYzqw8EF6l7ZDGBmlqhAazlYshQ0tuUf3PZG 3WvV1nJRO6Vo5dQdYlbNRPIlHBTKQEvIj49OBsPpV6gF4pucA0tKFQBdR6dCpQibgwe4 l0G8gioshwrF9axJnGwa8q7/DSALxaGBbwmv+Eol2Z7hqOqmgDgvYm51uOejjI9++9/G k14Q== X-Forwarded-Encrypted: i=1; AFNElJ+o/cfBe0j6tOKfwkfnRS9DTml0GtENZUNBtmNW1mlIe5Fz515VwL0y59UuRNkkbq85FXOb1QWC++ujNMU=@vger.kernel.org X-Gm-Message-State: AOJu0YyNgfMUa5ZK8Bto2wKNkf3TnvayeR6XHgSr09YBjBuYVAnAXPp5 QBImrj6ZllCOhlbjc6fL6+gpuDSguxEB1EGvEZKQRRiF28gsXDvxvHS3 X-Gm-Gg: AeBDieuMshUMGriCMklc1+xc1m/A8K6ky2PoTJTy3dBurpIGh9pCrlevrB4InCkjn2N wUnXcLP8sqjlqGz6KGzKdJ9XAPuFQyhwFRkl7uz+vGiEk/8LauKK2WM5ckuzcrhCz1AMJAVXjTW l20cRQm/ruXZoYK+9KgI32ZSWc4j5GBbVc+pY/oqKcusOefHg0j9WVrKNlL0OKmS6w3EugMG+hm FLt6zQWV3N9/onSxzcfiYVzPhHE1WKDyuDSgGEOiipVlzMUEL2r/4bhAsbezYBFO91WqF3ZtHU2 ziXR1AN0DXDeH3tSvLR5ygDLQGwp4yvg2pHpXroPUVXyC55Q9x/cdi9lBZAFQme9t9Xepi6kQN6 +OimwV6ZT6ygNKYxPZmpfux5nABo1IWzo+/m9YkrkD5k+7pS/Xb97ISjB981sXBLBVmwtOmh4HO ZdyPcUqap2uAPKJiu5GsYQnNEOv+9aEzLkQ5YMZOoIOU9tEgMlR3tsUnmNFHkASV+iruChllYd/ cmWIKO2BGJqSpQqKasitUGTqog2eC0= X-Received: by 2002:a05:620a:241c:10b0:8ea:b828:350d with SMTP id af79cd13be357-8eab828370fmr236380585a.11.1776633734532; Sun, 19 Apr 2026 14:22:14 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8e7d65c1321sm654849185a.15.2026.04.19.14.22.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Apr 2026 14:22:13 -0700 (PDT) From: Michael Bommarito To: Jan Kara Cc: Edward Adam Davis , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH 0/2] isofs: hardening for crafted CE and NFS-handle paths Date: Sun, 19 Apr 2026 17:21:53 -0400 Message-ID: <20260419212155.2169382-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Two small defensive bounds checks for the ISO 9660 filesystem, one in Rock Ridge CE continuation handling and one in the NFS export path. Both surfaced while looking for missing bounds checks adjacent to recently-landed isofs fixes (0405d4b63d08, f54e18f1b831). Neither is a memory-safety bug on its own; the existing sb_bread() / isofs_iget() paths handle out-of-range blocks cleanly. These patches reject the malformed input at the earliest point it is known to be out of range. 1/2: rock_continue() reads rs->cont_extent from the Rock Ridge CE record and calls sb_bread() on it without validating the block number against ISOFS_SB(sb)->s_nzones. commit e595447e177b (2005) added the cont_offset and cont_size rejection but left the extent number unchecked; commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain at RR_MAX_CE_ENTRIES = 32 but again did not address the block number. The reachable attacker model is a crafted ISO auto-mounted via udisks2 / polkit on a desktop session; sb_bread() on an out-of-range block returns NULL cleanly, so there is no memory-safety issue, and the CE buffer is parsed as Rock Ridge records rather than returned verbatim via readlink(). 2/2: isofs_fh_to_dentry() and isofs_fh_to_parent() pass attacker-controlled block numbers from the NFS file handle to isofs_export_iget(), which rejects block == 0 but not out-of-range block numbers. commit 0405d4b63d08 ("isofs: Prevent the use of too small fid", CVE-2025-37780) added fh_len checks but left the block number itself unchecked. An authenticated NFS peer with a crafted fid can drive reads of adjacent-partition data on the same block device into iso_inode_info fields reaching the client as dentry metadata. Deployment surface is narrow (isofs-over-NFS); impact is primarily EIO / ESTALE with a weak info-leak channel. Both patches are one-line (or close to it) additions; the existing out-of-range-block check in isofs_iget() / sb_bread() handles the read-side cleanly, so these are strictly belt-and-suspenders rejection at the earliest point we know the input is out of range. Build-tested W=1 against 7.0-rc7 with CONFIG_ISO9660_FS=y, CONFIG_JOLIET=y, CONFIG_ZISOFS=y. Michael Bommarito (2): isofs: validate Rock Ridge CE continuation extent against volume size isofs: validate block number from NFS file handle in isofs_export_iget fs/isofs/export.c | 2 +- fs/isofs/rock.c | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) -- 2.53.0