Re: [PATCH] qnx4: fix to avoid panic due to buffer overflow

[Ronald Monthero]

On Tue, Nov 14, 2023 at 1:40 AM Anders Larsen <al@xxxxxxxxxxx> wrote:
>
< Snipped>
>
> sizeof(de->di_fname) is evaluated as QNX4_SHORT_NAME_MAX already at compile
> time, see the definition of di_fname in uapi/linux/qnx4_fs.h
>
> I agree that the code is confusing, as 'de' is declared as a pointer to a
> struct qnx4_inode_entry but in reality points to a struct qnx4_link_info iff
> QNX4_FILE_LINK is set in de->di_status.
> (Note that the corresponding field dl_status in qnx4_link_info is at the same
> offset as di_status in qnx4_inode_entry - that's the disk layout.)
>

Thanks for the details, yes in  struct qnx4_inode_entry  its size
char di_fname[QNX4_SHORT_NAME_MAX];

< snipped>
>
> Niek reported that this fix improved the situation, but he later got a crash,
> albeit at a different place (but still within the qnx4fs).

Yes I saw that Niek has shared the second crash dump stack in above email thread
and also in [1] Bugzilla 218111.The dump stack of the crash looks to
be doing a similar
lookup call context, do_statx => vfs_statx => filename_lookup =>
qn4x_lookup => fortify_panic ( )
[1] https://bugzilla.kernel.org/show_bug.cgi?id=218111#c4

But  I also see a softlockup also in the dump stack, so something in
their environment
is causing softlock ups.  And that tallies with the symptoms of system
freeze that Niek
mentioned " I can mount and view the directories, but after several hours
my system froze up again."

watchdog: BUG: soft lockup - CPU#7 stuck for 26s! [pool-gvfsd-admi:31952]   <<<<

It's possible the softlockups were occurring on fews of the CPUs on the system
for a few hours before the crash occurred that caused a system slow down.

BR,
Ronald