All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+969e250fc7983fc7417c@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] udf: propagate iteration error from udf_expand_dir_adinicb()
Date: Fri, 17 Apr 2026 03:12:15 -0700	[thread overview]
Message-ID: <69e2077f.050a0220.1de265.000e.GAE@google.com> (raw)
In-Reply-To: <683ea90b.a00a0220.d8eae.0060.GAE@google.com>

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] udf: propagate iteration error from udf_expand_dir_adinicb()
Author: tristmd@gmail.com

From: Tristan Madani <tristan@talencesecurity.com>

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


udf_expand_dir_adinicb() copies inline directory data into a newly
allocated block and then re-iterates the directory entries to fixup tag
locations.  If the iteration fails (e.g. due to I/O error reading the
new block or corrupted on-disk data), the function hits a WARN_ON_ONCE()
and silently returns success.

On a crafted UDF image this WARNING fires reliably because the
underlying block read fails, causing udf_fiiter_init() or
udf_fiiter_advance() to return -EFSCORRUPTED.

Fix this by removing the WARN_ON_ONCE() and propagating the error code
to the caller instead, so that filesystem corruption is handled
gracefully rather than triggering a kernel warning.

Fixes: a27b2923de7e ("udf: Move udf_expand_dir_adinicb() to its callsite")
Reported-by: syzbot+969e250fc7983fc7417c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=969e250fc7983fc7417c
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
 fs/udf/namei.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/fs/udf/namei.c b/fs/udf/namei.c
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -206,15 +206,11 @@ static int udf_expand_dir_adinicb(struct inode *inode, udf_pblk_t *block)
 		else
 			impuse = NULL;
 		udf_fiiter_write_fi(&iter, impuse);
 	}
 	brelse(dbh);
-	/*
-	 * We don't expect the iteration to fail as the directory has been
-	 * already verified to be correct
-	 */
-	WARN_ON_ONCE(ret);
 	udf_fiiter_release(&iter);

-	return 0;
+	return ret;
 }

 static int udf_fiiter_add_entry(struct inode *dir, struct dentry *dentry,
--
2.39.5

  reply	other threads:[~2026-04-17 10:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03  7:49 [syzbot] [udf?] WARNING in udf_fiiter_add_entry syzbot
2026-04-17 10:12 ` syzbot [this message]
2026-04-17 16:21 ` Forwarded: Re: [syzbot] " syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69e2077f.050a0220.1de265.000e.GAE@google.com \
    --to=syzbot+969e250fc7983fc7417c@syzkaller.appspotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.