[OpenIndiana-discuss] kernel panic when opening file viewer to check files on an NTFS file system
Jean-Pierre André
jean-pierre.andre at wanadoo.fr
Sat Dec 14 16:22:53 UTC 2024
Hi again,
The source argument of the strlcpy() is
vfssw[vfsp->vfs_fstype].vsw_name
and the problem is that "struct vfssw" is now 136 bytes long
instead of 128 in the compiled code, due to a recent change
in some vm/*.h which I have not identified.
So the fuse module has not been recompiled along with that
change, and what has to be done is just recompiling it.
I really cannot understand how this can happen. There must
be a defect in the kernel recompilation procedure. The fuse
kernel module is plugged into the kernel just like normal
file systems, and it has to be recompiled whenever a kernel
structure changes.
Jean-Pierre
Toomas Soome via openindiana-discuss wrote on 12/14/24 12:59 PM:
>
>
>> 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
>
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
More information about the openindiana-discuss
mailing list