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@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@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@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@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org <mailto:openindiana-discuss@openindiana.org>
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org <mailto:openindiana-discuss@openindiana.org>
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
