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

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CALk6UxqF26rpNi1wD1Q8VmX6X-woe5YuuRK-Uk7bNcwqsRFKZA@mail.gmail.com>
Date: Wed, 15 Nov 2023 00:38:21 +1000
From: Ronald Monthero <debug.penguin32@...il.com>
To: Anders Larsen <al@...rsen.net>
Cc: keescook@...omium.org, gustavoars@...nel.org, linux-kernel@...r.kernel.org, 
	linux-hardening@...r.kernel.org, Niek Nooijens <nieknooijens@...il.com>
Subject: Re: [PATCH] qnx4: fix to avoid panic due to buffer overflow

On Tue, Nov 14, 2023 at 1:40 AM Anders Larsen <al@...rsen.net> 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