Bug 2158164

Created attachment 1935707 [details]
File: proc_pid_status

Created attachment 1935708 [details]
File: maps

Created attachment 1935709 [details]
File: limits

Created attachment 1935710 [details]
File: environ

Created attachment 1935711 [details]
File: open_fds

Created attachment 1935712 [details]
File: mountinfo

Created attachment 1935713 [details]
File: os_info

Created attachment 1935714 [details]
File: cpuinfo

Created attachment 1935715 [details]
File: core_backtrace

Created attachment 1935716 [details]
File: exploitable

Created attachment 1935717 [details]
File: dso_list

Created attachment 1935718 [details]
File: backtrace

Created attachment 1935719 [details]
archive which caused this crash

Hi Mikhail, does a file in your archive start with ".." - two dots in its name?

Created attachment 1935750 [details]
screenshot

(In reply to Jindrich Novy from comment #14)
> Hi Mikhail, does a file in your archive start with ".." - two dots in its
> name?

Yes, but not idea how it's possible. It not mine archive, I downloaded it from tracktion.com site.

https://cdn.tracktion.com/file/tracktiondownloader/retromod/digital1/content/10/demo/retromod_digital_1_demo_content_v1_install_script.zip?Authorization=3_20230104143111_0859a4d4a662579e1ec353a5_d037d232b5e580141e0b5c6fca1a4ef02b500125_001_20230105023111_0033_dnld

Wrote a simple patch to "fix" this:

diff -up mc-4.8.28/src/vfs/extfs/extfs.c.jnovy mc-4.8.28/src/vfs/extfs/extfs.c
--- mc-4.8.28/src/vfs/extfs/extfs.c.jnovy	2022-03-27 13:54:06.000000000 +0200
+++ mc-4.8.28/src/vfs/extfs/extfs.c	2023-01-04 15:55:08.081396288 +0100
@@ -254,8 +254,15 @@ extfs_find_entry_int (struct vfs_s_inode
         *q = '\0';
 
         if (DIR_IS_DOTDOT (p))
-            pent = pent->dir->ent;
-        else
+        {
+            if (pent->dir)
+            {
+              pent = pent->dir->ent;
+            } else
+            {
+              pent = NULL;
+            }
+        } else
         {
             GList *pl;

But ultimately I suggest to contact upstream - and report it there given it's so easily reproducible: http://midnight-commander.org/report

Just created the upstream report here: https://midnight-commander.org/ticket/4422

Created attachment 1935826 [details]
PowerZip screenshot

(In reply to Jindrich Novy from comment #16)
> Wrote a simple patch to "fix" this:
> 
> diff -up mc-4.8.28/src/vfs/extfs/extfs.c.jnovy
> mc-4.8.28/src/vfs/extfs/extfs.c
> --- mc-4.8.28/src/vfs/extfs/extfs.c.jnovy	2022-03-27 13:54:06.000000000 +0200
> +++ mc-4.8.28/src/vfs/extfs/extfs.c	2023-01-04 15:55:08.081396288 +0100
> @@ -254,8 +254,15 @@ extfs_find_entry_int (struct vfs_s_inode
>          *q = '\0';
>  
>          if (DIR_IS_DOTDOT (p))
> -            pent = pent->dir->ent;
> -        else
> +        {
> +            if (pent->dir)
> +            {
> +              pent = pent->dir->ent;
> +            } else
> +            {
> +              pent = NULL;
> +            }
> +        } else
>          {
>              GList *pl;
 
After applying this patch I am unable to enter in this archive with mc. So it still looks like an error. If displaying ".." is problematic, you can replace them with the word "__Parent__". This is what some archivators on MacOS do, for example PowerZip.

(In reply to Jindrich Novy from comment #16)
> Wrote a simple patch to "fix" this:
> 
> diff -up mc-4.8.28/src/vfs/extfs/extfs.c.jnovy
> mc-4.8.28/src/vfs/extfs/extfs.c
> --- mc-4.8.28/src/vfs/extfs/extfs.c.jnovy	2022-03-27 13:54:06.000000000 +0200
> +++ mc-4.8.28/src/vfs/extfs/extfs.c	2023-01-04 15:55:08.081396288 +0100
> @@ -254,8 +254,15 @@ extfs_find_entry_int (struct vfs_s_inode
>          *q = '\0';
>  
>          if (DIR_IS_DOTDOT (p))
> -            pent = pent->dir->ent;
> -        else
> +        {
> +            if (pent->dir)
> +            {
> +              pent = pent->dir->ent;
> +            } else
> +            {
> +              pent = NULL;
> +            }
> +        } else
>          {
>              GList *pl;
> 
> But ultimately I suggest to contact upstream - and report it there given
> it's so easily reproducible: http://midnight-commander.org/report

{leasse submit that patch as PR on https://github.com/MidnightCommander/mc/

(In reply to Tomasz Kłoczko from comment #19)

> > But ultimately I suggest to contact upstream - and report it there given
> > it's so easily reproducible: http://midnight-commander.org/report
> 
> {leasse submit that patch as PR on https://github.com/MidnightCommander/mc/

Please don't do this, we ask to use our bug tracker instead of PRs on GitHub.

> Please don't do this, we ask to use our bug tracker instead of PRs on GitHub.

This is not about tracking bug but about evaluating proposed fix by mc maintainer.

(In reply to Tomasz Kłoczko from comment #21)
> > Please don't do this, we ask to use our bug tracker instead of PRs on GitHub.
> 
> This is not about tracking bug but about evaluating proposed fix by mc
> maintainer.

I *am* the maintainer and I'm kindly asking you to please NOT encourage others send us PRs, but send patches to our tracker instead if necessary instead.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

This message is a reminder that Fedora Linux 38 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '38'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 38 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.