[OpenIndiana-discuss] kernel panic when opening file viewer to check files on an NTFS file system

Toomas Soome tsoome at me.com
Sat Dec 14 11:59:33 UTC 2024 


> On 14. Dec 2024, at 12:49, Jean-Pierre André via openindiana-discuss <openindiana-discuss at openindiana.org> wrote:
> 
> Hi,
> 
> See below
> 
> Jean-Pierre
> 
> Toomas Soome via openindiana-discuss wrote on 12/14/24 9:11 AM:
>>> On 14. Dec 2024, at 09:32, Jean-Pierre André via openindiana-discuss <openindiana-discuss at openindiana.org> wrote:
>>> 
>>> Hi,
>>> 
>>> Please post the output of
>>> fmdump -Vp -u c0c54af8-4972-4f2c-85ba-c20b0272ea0b
>>> 
>>> Also post the record from /var/adm/messages similar to :
>>> fuse: [ID 295230 kern.info] Fuse kernel init at 0xff....
>>> 
>>> Subsequent records related to ntfs-3g may also help.
>>> 
>>> Jean-Pierre
>> panicstack = unix:die+c0 () | unix:trap+999 () | unix:cmntrap+e9 () | unix:strlen+0 () | fuse:fuse_statvfs+117 () | genunix:fsop_statfs+1d () | genunix:cstatvfs64_32+44 () | genunix:statvfs64_32+76 () | unix:brand_sys_sysenter+1d2 () |
>> so we appear to call strlen() from fuse_statvfs() and this strlen is used with NULL pointer.
> 
> 
> Strange : at fuse_statvfs+117 I have an strlcpy(), not strlen().

> strlcpy::dis
strlcpy:                        pushq  %rbp
strlcpy+1:                      movq   %rsp,%rbp
strlcpy+4:                      subq   $0x40,%rsp
strlcpy+8:                      movq   %rdi,-0x8(%rbp)
strlcpy+0xc:                    movq   %r12,-0x38(%rbp)
strlcpy+0x10:                   movq   %rdx,%r12
strlcpy+0x13:                   movq   %r13,-0x30(%rbp)
strlcpy+0x17:                   movq   %rdi,%r13
strlcpy+0x1a:                   movq   %rsi,%rdi
strlcpy+0x1d:                   movq   %rbx,-0x40(%rbp)
strlcpy+0x21:                   movq   %r14,-0x28(%rbp)
strlcpy+0x25:                   movq   %rsi,%r14
strlcpy+0x28:                   movq   %rdx,-0x18(%rbp)
strlcpy+0x2c:                   movq   %rsi,-0x10(%rbp)
strlcpy+0x30:                   call   -0x2ebb5 <strlen>
strlcpy+0x35:                   testq  %r12,%r12
strlcpy+0x38:                   movq   %rax,%rbx
strlcpy+0x3b:                   je     +0x23    <strlcpy+0x60>
strlcpy+0x3d:                   leaq   -0x1(%r12),%rax
strlcpy+0x42:                   cmpq   %r12,%rbx
strlcpy+0x45:                   movq   %r13,%rsi
strlcpy+0x48:                   movq   %r14,%rdi
strlcpy+0x4b:                   cmovq.b %rbx,%rax
strlcpy+0x4f:                   movq   %rax,%r12
strlcpy+0x52:                   movq   %rax,%rdx
strlcpy+0x55:                   call   -0x3b9ca <bcopy>
strlcpy+0x5a:                   movb   $0x0,0x0(%r13,%r12)
strlcpy+0x60:                   movq   %rbx,%rax
strlcpy+0x63:                   movq   -0x38(%rbp),%r12
strlcpy+0x67:                   movq   -0x40(%rbp),%rbx
strlcpy+0x6b:                   movq   -0x30(%rbp),%r13
strlcpy+0x6f:                   movq   -0x28(%rbp),%r14
strlcpy+0x73:                   leave  
strlcpy+0x74:                   ret  

So strlcpy does use strlen, and I guess thats where we do blow up. 

size_t
strlcpy(char *dst, const char *src, size_t len)
{
        size_t slen = strlen(src);
        size_t copied;

        if (len == 0)
                return (slen);

        if (slen >= len)
                copied = len - 1;
        else
                copied = slen;
        bcopy(src, dst, copied);
        dst[copied] = '\0';
        return (slen);
}

We do not want to pass unchecked src to strlcpy().

Unfortunately the issue does not expose stack trace with function arguments, so we can only guess right now.

rgds,
toomas

> 
> The source of the strlcpy() is the file system type, which, as far
> as I understand, is provided by /usr/lib/fs/ntfs-3g/fstyp, the
> copy length is the constant 16, no strlen() used.
> 
> On my computer I get :
> [root at openindiana amd64]# /usr/lib/fs/ntfs-3g/fstyp /dev/dsk/c5t2d0p1
> ntfs-3g
> 
>> rgds,
>> toomas
>>> 
>>> Apostolos Syropoulos via openindiana-discuss wrote on 12/13/24 11:06 PM:
>>> 
>>>> Hi,
>>>> I have an external USB disk that has an NTFS file system.  I am using
>>>> the command
>>>> # ntfs-3g /dev/dsk/c13t0d0p1 /mnt/
>>>> to mount the file system and everything works just fine, However,when I try to inspect  the folder /mnt with the file viewer thesystem crashes (I am using illumos-9d4bc241fd, October 2024).Here are the relevant details that dmesg gave me:
>>>>  Dec 13 21:55:11 adalind savecore: [ID 570001 auth.error] reboot after panic: BAD
>>>>  TRAP: type=e (#pf Page fault) rp=fffffe001113cc50 addr=0 occurred in module "un
>>>> ix" due to a NULL pointer dereference
>>>> Dec 13 21:55:13 adalind savecore: [ID 970367 auth.error] Panic crashdump pending
>>>>  on dump device but dumpadm -n in effect; run savecore(8) manually to extract. I
>>>> mage UUID c0c54af8-4972-4f2c-85ba-c20b0272ea0b.
>>>> Dec 13 21:55:32 adalind fmd: [ID 377184 daemon.error] SUNW-MSG-ID: SUNOS-8000-KL
>>>> , TYPE: Defect, VER: 1, SEVERITY: Major
>>>> Dec 13 21:55:32 adalind EVENT-TIME: Fri Dec 13 21:55:31 EET 2024
>>>> Dec 13 21:55:32 adalind PLATFORM: To-be-filled-by-O.E.M., CSN: To-be-filled-by-O
>>>> .E.M., HOSTNAME: adalind
>>>> Dec 13 21:55:32 adalind SOURCE: software-diagnosis, REV: 0.1
>>>> Dec 13 21:55:32 adalind EVENT-ID: c0c54af8-4972-4f2c-85ba-c20b0272ea0b
>>>> Dec 13 21:55:32 adalind DESC: The system has rebooted after a kernel panic.  Ref
>>>> er to http://illumos.org/msg/SUNOS-8000-KL for more information.
>>>> Dec 13 21:55:32 adalind AUTO-RESPONSE: The failed system image was dumped to the
>>>>  dump device.  If savecore is enabled (see dumpadm(8)) a copy of the dump will b
>>>> e written to the savecore directory .
>>>> Dec 13 21:55:32 adalind IMPACT: There may be some performance impact while the p
>>>> anic is copied to the savecore directory.  Disk space usage by panics can be sub
>>>> stantial.
>>>> Dec 13 21:55:32 adalind REC-ACTION: If savecore is not enabled then please take
>>>> steps to preserve the crash image.
>>>> Dec 13 21:55:32 adalind Use 'fmdump -Vp -u c0c54af8-4972-4f2c-85ba-c20b0272ea0b'
>>>>  to view more panic detail.  Please refer to the knowledge article for additiona
>>>> l information.
>>>> Can anybody tell me what is happening? This is the first time I see such a thing.
>>>> Regards,Apostolos
>>>> ----------------------Apostolos Syropoulos
>>>> Xanthi, Greece
>>>> _______________________________________________
>>>> openindiana-discuss mailing list
>>>> openindiana-discuss at openindiana.org
>>>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> openindiana-discuss mailing list
>>> openindiana-discuss at openindiana.org
>>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>> _______________________________________________
>> openindiana-discuss mailing list
>> openindiana-discuss at openindiana.org <mailto:openindiana-discuss at openindiana.org>
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
> 
> 
> 
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org <mailto:openindiana-discuss at openindiana.org>
> https://openindiana.org/mailman/listinfo/openindiana-discuss

More information about the openindiana-discuss mailing list