lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Nov 2023 00:38:21 +1000
From: Ronald Monthero <>
To: Anders Larsen <>
Cc:,,,, Niek Nooijens <>
Subject: Re: [PATCH] qnx4: fix to avoid panic due to buffer overflow

On Tue, Nov 14, 2023 at 1:40 AM Anders Larsen <> 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 ( )

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.


Powered by blists - more mailing lists