I wasn't able to obtain corefile from end-user, but saw in his smbd log following:

```
2022/12/25 15:38:18.037892,  0] ../../lib/util/fault.c:184(smb_panic_log)
  PANIC (pid 17385): Signal 11: Segmentation fault in 4.15.11
[2022/12/25 15:38:18.043928,  0] ../../lib/util/fault.c:288(log_stack_trace)
  BACKTRACE: 10 stack frames:
   #0 0x8014ab8c7 <log_stack_trace+0x37> at /usr/local/lib/samba4/libsamba-util.so.0
   #1 0x8014ab9a1 <smb_panic+0x11> at /usr/local/lib/samba4/libsamba-util.so.0
   #2 0x8014ab719 <fault_setup+0xa9> at /usr/local/lib/samba4/libsamba-util.so.0
   #3 0x80193b6d0 <pthread_sigmask+0x540> at /lib/libthr.so.3
   #4 0x80193ac8f <pthread_setschedparam+0x82f> at /lib/libthr.so.3
   #5 0x7ffffffff8a3 <???> at ???
   #6 0x804ce91e5 <memset+0xd5> at /lib/libc.so.7
   #7 0x804d5aaae <strncpy+0x3e> at /lib/libc.so.7
   #8 0x80519fd7c <rep_listxattr+0x1fc> at /usr/local/lib/samba4/private/libreplace-samba4.so
   #9 0x801b985c4 <vfs_default_init+0x8a34> at /usr/local/lib/samba4/private/libsmbd-base-samba4.so
```

Which caused me to look into rep_listxattr implementation on FreeBSD and I noticed there isn't handling for case where FreeBSD returns a truncated xattr list.

In case of truncated xattr list, the pascal string will still reference the full length of the xattr name, but it will not be included in the returned buffer. This somewhat less than felicitously encourages consumers to accidentally read off the end of the array.

Fix is fairly trivial. Filing bug ticket to get number to then make gitlab merge request.