From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) (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 9C9EC45107A for ; Tue, 19 May 2026 12:48:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779194932; cv=none; b=Utzz8iEDVbetbiAKg+GtsS2gGTdEcaiNGMbDTHZJC91eDNDnlWGynK+O7jJvtaqUtgKj8qAG4En6gKjMdVcjo3WpyYj+px6UsKY4014jwNbkq+7h4rdOvKCe4640y1cu38W+09KCzh/DtEwl4qW93fHVQWXdDqTYrQ8LvA1pWKk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779194932; c=relaxed/simple; bh=y0Lhp5/BCsgbf8DQ3cQRLuZnzrjLo/N1F265iVj1gTM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=f+5vh7wcqORT5Kp8xKseKvy/yJcx1lLt5xf9BEvw0Se7TvOK8j2jXuKnf+sne+SMjYrabo+9aqRTIlwU9dwJ1tHqxh9wM1IjAO6eXM1wbll5hB4OxoGQczNBWCLa1ikB/CvziMbqsQlNUZXDGWJHhfA8IUa1jbO56OWNlvuBrxw= 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=lQ0c016B; arc=none smtp.client-ip=209.85.219.41 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="lQ0c016B" Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-8bb4e8a5240so48280286d6.1 for ; Tue, 19 May 2026 05:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779194930; x=1779799730; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Mayj3mKodS45dh24BWdqAhTjWaDxUFyowh6qUvPhU9s=; b=lQ0c016B/hrRD7NA3M47SCqNaYh7QlZGZ1QJApAK7VZsjo6kbTC0T2yR2LoJ5FqWbH HHP4SjBliVeFZnj5PyJR+a5pLqcA3vf7aoccNfPFKpeo9Be1wr5bYRPc7H/5BuHGDy2E 7KfpAG8gZ/B2ebdi1r7l9FPBcSSg1iNmZoatwW38nfSnl0XjUKdUFdWDQP41uUvMqV+b 3dQ8GLt50V613VnBBXCdEr9sGaSQtUfu4jmxdZpp68bfj7zXwg+GmbAlcd+B8ojPkOSU NxwB1qgYGI/uFePwwax2pQikAqlpz7Qv6boPJAL2Yd4FP2uHqQNBh28Vo/O0scInAxUQ /++w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779194930; x=1779799730; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Mayj3mKodS45dh24BWdqAhTjWaDxUFyowh6qUvPhU9s=; b=ojgaxUrSCP0TI+B7ENe1nYeDDooDsvx5JHdzsf8DTdMY82cWTJ4AuKumRQy2TPBdef j0bp2G2n/PObEXrwusKIX9wu+k1buNB0I2LFILhO/AyvDi0O01TKHrduk8pmkmc52EOQ qLAtR7tc9iMzPqw8KNxT39qJKlEa/KqEUwVpkvufuygR/2p266uy1J8X/4StE3WLLFyI eQHZKUtIBuMHYxI2aBqMLmj/qVS9HQk7+nvjNex6hSnSAKMFX0WOw9wopk8iUw2lAO0Q gNG31DxPjO/DZQgw1MNGjs/cRAQvmjAut0xG2Bj6qIDXmdLi+8Zk6mBAeYu0M1uP33cb 2mcg== X-Forwarded-Encrypted: i=1; AFNElJ8rGueSZvO/VnvDfd8HQ6Kb+5mIg+JJeRtZSCqW1hfns6qozP8OceBmhsGpQVFYE7NlzhvPayW3Mh+D52g=@vger.kernel.org X-Gm-Message-State: AOJu0Yxo72sPLmQECSQ7unR2d1b44uzqdpu4f+3PJkLe3APk2WDvfbZ+ JQxJZsUhxNQe/2+hVYleGK+G5pfktCddoxPf3egcm779NG65y7kZp5rw9dwOKxwK X-Gm-Gg: Acq92OHV4/I+8XIWwRerXpn1IHBchIuobOAit0tDjJ/Adiya7A+8xI6L7JOMoR/NgKF 1aFC5+eQ1yts/qpyV1tx66KThBsLBJuSgEVWCqagut/G3L3wvY0G1Ut5RN0RBbNzyQtgvQfRVf/ 1WgObfiReesLVG0/0aBONNOessvdMAK9OvbW2rtPiom1pQw0H34BiI3fRnp5EDBT4tbg4NeVpay Js3rFkrF6Vt4D5UR5O25R+b64HTRhh+gJxqzzQOB34T/kx46rzP61b8pekhSLcGe4KmNxpwXqTv awRw6NGATBzAELVIxy1sKIVueZTMl7YglEXnPeAQSgKPAxU+u3EGbslRS1AqqUAGfsE0PpKmqzL hQC4LtNfEc+fUZWp8NdMzwZ1KwD+NQ4iuQaGDbFK3lk0wmksrvLgHjxROeS2fSloWHOynbMqvyz GtytZ+qXEpdR+gEd2LRiToLr9NPOxSS6Ycg4uuaFWto+5NGW2bEGkW0wcPz0qZqIdy0VNupJmG2 F9txKWDFs8nacrq/UyCNtoo1H6A3gI= X-Received: by 2002:a05:6214:428d:b0:89c:4ea7:a70f with SMTP id 6a1803df08f44-8ca0f6353cdmr280438626d6.14.1779194930452; Tue, 19 May 2026 05:48:50 -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 6a1803df08f44-8ca361905d4sm88391606d6.32.2026.05.19.05.48.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 05:48:49 -0700 (PDT) From: Michael Bommarito To: Christoph Hellwig Cc: "Darrick J. Wong" , Carlos Maiolino , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xfs: detect cycles in recovered unlinked inode lists Date: Tue, 19 May 2026 08:48:33 -0400 Message-ID: <20260519124833.2020871-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: <20260518013143.1532327-1-michael.bommarito@gmail.com> <20260519050235.GI9568@frogsfrogsfrogs> 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=us-ascii Content-Transfer-Encoding: 7bit Hi Christoph, This research agenda and patch comes from a hardening project focused on automount filesystems in major modern distros. Maybe the USB stick threat model isn't worth the patch for just DoS impact, but that's at least why I thought it worth submitting in the first place. I looked more closely at current xfsprogs for-next to answer Darrick's repair question. Plain xfs_repair refuses the reproducer because the log is dirty and needs replay; that replay is the mount-time path that hangs on the vulnerable kernel. xfs_repair -n diagnoses the AGI unlinked bucket and inode next_unlinked damage, and xfs_repair -L clears the bucket / next_unlinked state and repairs the image, with the usual log-loss caveat. I also found a narrower userspace diagnostic issue: xfs_db dump_iunlinked follows di_next_unlinked until NULLAGINO and will spin on the same self-cycle. xfs_repair itself does not appear to use that unbounded walker in the tested repair path, and xfs_scrub userspace is mostly driving the kernel scrub ioctls. To be fully safe from automount attacks, I think both sides would need to be addressed. Your bigger point about regressions and test coverage is still valid though. FWIW, I have been talking with some other fs maintainers about adding test/ fuzzing coverage either in-tree or external. I would be happy to help with add XFS coverage as part of that project, although I'd defer to your preference about where those tests should actually live. All that said, just let me know if you still want a v2 based on the threat model. Thanks, Mike