While debugging a syzbot report, I found that the %pS format in
dump_holder() can trigger a crash when we end up in the pr_err()
fallback path. This happens because %pS goes through symbol resolution
inside vsnprintf, and in this case that isn’t always safe.

I switched the seq_file case to continue using %pS, since it is useful
there, but changed the pr_err() path to use %p instead. This way we
still print a valid pointer address without risking a kernel oops from
within printk itself. The idea is to keep the debugging value but make
it more robust.

Fixes: 590b221ed425 ("Add linux-next specific files for 20250912")
Reported-by: syzbot+fa7122891ab9e0bbc6a7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fa7122891ab9e0bbc6a7

Signed-off-by: Kriish Sharma <kriish.sharma2006@gmail.com>
---
 fs/gfs2/glock.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index b677c0e6b9ab..903844a6ebbc 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -2284,10 +2284,18 @@ static void dump_holder(struct seq_file *seq, const struct gfs2_holder *gh,
 		if (gh_owner)
 			comm = gh_owner->comm;
 	}
-	gfs2_print_dbg(seq, "%s H: s:%s f:%s e:%d p:%ld [%s] %pS\n",
-		       fs_id_buf, state2str(gh->gh_state),
-		       hflags2str(flags_buf, gh->gh_flags, gh->gh_iflags),
-		       gh->gh_error, (long)owner_pid, comm, (void *)gh->gh_ip);
+	if (seq) {
+		gfs2_print_dbg(seq, "%s H: s:%s f:%s e:%d p:%ld [%s] %pS\n",
+			fs_id_buf, state2str(gh->gh_state),
+			hflags2str(flags_buf, gh->gh_flags, gh->gh_iflags),
+			gh->gh_error, (long)owner_pid, comm, (void *)gh->gh_ip);
+	} else {
+		gfs2_print_dbg(seq, "%s H: s:%s f:%s e:%d p:%ld [%s] %p\n",
+			fs_id_buf, state2str(gh->gh_state),
+			hflags2str(flags_buf, gh->gh_flags, gh->gh_iflags),
+			gh->gh_error, (long)owner_pid, comm,
+			(void *)gh->gh_ip);
+	}
 	rcu_read_unlock();
 }
 
-- 
2.34.1

On Tue, Sep 16, 2025 at 11:12 PM Kriish Sharma
<kriish.sharma2006@gmail.com> wrote:
> While debugging a syzbot report, I found that the %pS format in
> dump_holder() can trigger a crash when we end up in the pr_err()
> fallback path. This happens because %pS goes through symbol resolution
> inside vsnprintf, and in this case that isn’t always safe.

I'm unconvinced -- when and why is %pS not safe to use?

Thanks,
Andreas