From: Matthias Goergens <matthias.goergens@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Thomas Schmitt <scdbackup@gmx.net>,
linux-fsdevel@vger.kernel.org,
Matthias Goergens <matthias.goergens@gmail.com>
Subject: [PATCH] isofs: Always advance to the next block in readdir and lookup
Date: Wed, 23 Sep 2026 23:31:34 +0800 [thread overview]
Message-ID: <20260923153134.771632-1-matthias.goergens@gmail.com> (raw)
In-Reply-To: <20260922121912.2258134-2-jack@suse.cz>
Commit 3c01d9263683 ("isofs: Fix handling of directories with tight
blocks") made do_isofs_readdir() and isofs_find_entry() move on to the
next block with pos = round_up(pos, bufsize) both when a record ends
exactly at the end of the block and when the next length byte is zero.
In the second case pos is already block aligned if the zero byte is the
first byte of a block, so round_up() leaves it unchanged, the same block
is read again, and the loop never terminates. There is no
fatal_signal_pending() check in either loop, so the task spins at 100%
CPU and cannot be killed, and a second lookup of the same name blocks in
d_alloc_parallel() and trips the hung task detector.
A block that starts with a zero byte inside a directory is reachable
with a single-byte change to an image made by xorrisofs, and without
any corruption when the logical block size is 512 or 1024 bytes:
ECMA-119 zero-pads a directory only up to the end of the 2048-byte
logical sector, so the later logical blocks of a sector that is less
than full start with zero bytes and lie within the directory's size.
In both walkers pos equals (block << bufbits) + offset, so the next
block is simply block + 1. Advance to it directly, which is right for
both cases.
Fixes: 3c01d9263683 ("isofs: Fix handling of directories with tight blocks")
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
Jan, this is on top of your for_next; feel free to fold it into
3c01d9263683 instead if that is easier before you send it to Linus.
fs/isofs/dir.c | 4 ++--
fs/isofs/namei.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/isofs/dir.c b/fs/isofs/dir.c
index 5e541e765f547..28741251d56e3 100644
--- a/fs/isofs/dir.c
+++ b/fs/isofs/dir.c
@@ -119,8 +119,8 @@ static int do_isofs_readdir(struct inode *inode, struct file *file,
if (offset >= bufsize || de->length[0] == 0) {
brelse(bh);
bh = NULL;
- ctx->pos = round_up(ctx->pos, bufsize);
- block = ctx->pos >> bufbits;
+ block++;
+ ctx->pos = (loff_t)block << bufbits;
offset = 0;
continue;
}
diff --git a/fs/isofs/namei.c b/fs/isofs/namei.c
index e1c571478e8f5..4fba1bf7f0167 100644
--- a/fs/isofs/namei.c
+++ b/fs/isofs/namei.c
@@ -82,8 +82,8 @@ isofs_find_entry(struct inode *dir, struct dentry *dentry,
if (offset >= bufsize || de->length[0] == 0) {
brelse(bh);
bh = NULL;
- f_pos = round_up(f_pos, bufsize);
- block = f_pos >> bufbits;
+ block++;
+ f_pos = block << bufbits;
offset = 0;
continue;
}
base-commit: c8437ca3d4386af1ae1f2869643e82fdb9c1f0f5
--
2.55.0
next prev parent reply other threads:[~2026-09-23 15:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 12:19 [PATCH] isofs: Fix handling of directories with tight blocks Jan Kara
2026-09-22 14:59 ` Thomas Schmitt
2026-09-23 10:22 ` Jan Kara
2026-09-23 15:31 ` Matthias Goergens [this message]
2026-09-23 16:55 ` [PATCH] isofs: Always advance to the next block in readdir and lookup Jan Kara
2026-09-23 17:52 ` Matthias Goergens
2026-09-23 18:40 ` Jan Kara
2026-09-25 4:28 ` Matthias Goergens
2026-09-25 2:34 ` [syzbot ci] Re: isofs: Fix handling of directories with tight blocks syzbot ci
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=20260923153134.771632-1-matthias.goergens@gmail.com \
--to=matthias.goergens@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=scdbackup@gmx.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox