From nobody Thu Dec 18 19:12:57 2025 Received: from mail-oo1-f71.google.com (mail-oo1-f71.google.com [209.85.161.71]) (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 42039239567 for ; Thu, 11 Dec 2025 09:27:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.71 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765445261; cv=none; b=JthiAXWOAvRdeqBlcXzQkSQN/QMxAXnXVkfnhB+OnCxF0/KUlOj86eVvLPQJeixdjkSFdRVQtCkGOoyBO/gOzsOa2Vvi8inkNGTHstwbSWxQykcZTfeqs8rqZAqI7Gr0AOIwmNQ2kHcdVzyGjqKuoOUb2pwSbaXozFcJFRT/cR8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765445261; c=relaxed/simple; bh=bSyG2J8fclMUYxgW9CN27wnZx3JUYNdNhJE5FkG0nq8=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=BDLw+kL/rOwm4LnD7OKi2Fl5k6CntsEc1mjDeLs+ePrxcuc9AFomjA0Wj5HpykDICFyNBKSMP6BGYrQ26jMvy805RtzHnSREydIt1sR1bMqITLtVn+385gWktxur3xvLeSDoF9mBgMIVv6rqBTihlWGY8NZB78oZhOzqf07NFzo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.161.71 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oo1-f71.google.com with SMTP id 006d021491bc7-65b31ec93e7so1581339eaf.3 for ; Thu, 11 Dec 2025 01:27:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765445259; x=1766050059; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iAGyT5Hm1BP7Bc5NdvK7fGErdYNkPgy/5fdV0xDNaTI=; b=ZyD26e3XbqP/tmzkNTqcQ7pVSoGvTMqco6yu8uBBuz0yr+jAbt/rcv/l5KKL2GtrN1 ZhzB+3jRwNCTCWbNqRuCmC06DiVjOs9RbmlSQhJroNpGBVNDRjoEJfwFzvj148p6IMn3 /izNewknXSbcCSnQ6Wqnd5FawEIGKgLP4b74VlifNqfPY5qfvbxNUAOu/7cRkQW/sbhL gQOFOqbILrbdoI4mXEbYR7TwFKjnmUFTbbVVR/RzUE9ugc/flG47ho/cUASigR8eF6OO ElPZnh/+WF2OpapEWtH/mYsGwYulM0VFC8d6CWqeVKWGlGUIwM5wNIAqk/q5fPSmVJ5E q81Q== X-Gm-Message-State: AOJu0YySBO/6Q1v2yfCwYYIm5sSnK9rHFvIUycDic1ORDOu+Yu8ONyqn 3iXW9KXjbRASxUhm7BJkzz7SSkGvsrQQeizkjRp+J0JUvngY2b7VtsJCJlZ9k9yZUlokhL9c3T3 c9lFOv4niAi15pYQLD1UmTahfcDBVM+5olzpvMHlv+hzVfn9IgqQGrycSKJ4= X-Google-Smtp-Source: AGHT+IHcPi48AOGCo2cvljipGDPgp4GRVfSPs9JX4e1P+479V1pYvJ67d4JxM7+nOzbc3V4/e/EnA/dllJR65auQWL2FmI24ATIC Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:1b09:b0:659:9a49:8f03 with SMTP id 006d021491bc7-65b2acc721amr3406044eaf.20.1765445259395; Thu, 11 Dec 2025 01:27:39 -0800 (PST) Date: Thu, 11 Dec 2025 01:27:39 -0800 In-Reply-To: <693a631e.a70a0220.33cd7b.0028.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <693a8e8b.050a0220.4004e.02f8.GAE@google.com> Subject: Forwarded: [PATCH] ocfs2: validate inline directory i_size during inode read From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] ocfs2: validate inline directory i_size during inode read Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= master When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline directories. If the filesystem is corrupted, an inline directory's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inline directories have i_size <=3D id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data. Reported-by: syzbot+c897823f699449cc3eb4@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Dc897823f699449cc3eb4 Signed-off-by: Deepanshu Kartikey --- fs/ocfs2/inode.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index 8340525e5589..9eb364bef5c3 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -1521,6 +1521,21 @@ int ocfs2_validate_inode_block(struct super_block *s= b, } } =20 + if (S_ISDIR(le16_to_cpu(di->i_mode)) && + (di->i_dyn_features & cpu_to_le16(OCFS2_INLINE_DATA_FL))) { + struct ocfs2_inline_data *data =3D &di->id2.i_data; + + if (le64_to_cpu(di->i_size) > le16_to_cpu(data->id_count)) { + rc =3D ocfs2_error(sb, + "Invalid dinode #%llu: inline directory " + "i_size %llu exceeds id_count %u\n", + (unsigned long long)bh->b_blocknr, + (unsigned long long)le64_to_cpu(di->i_size), + le16_to_cpu(data->id_count)); + goto bail; + } + } + rc =3D 0; =20 bail: --=20 2.43.0