Summary: | net/samba413: INTERNAL ERROR: Signal 11: Segmentation fault in pid xxxxx; problem with vfs_dirsort | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Joshua Kinard <freebsd> | ||||||
Component: | Individual Port(s) | Assignee: | Timur I. Bakeyev <timur> | ||||||
Status: | New --- | ||||||||
Severity: | Affects Only Me | CC: | freebsd, me, peter, rene | ||||||
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(timur) |
||||||
Version: | Latest | ||||||||
Hardware: | amd64 | ||||||||
OS: | Any | ||||||||
Attachments: |
|
Description
Joshua Kinard
2020-04-18 04:09:26 UTC
Adding an update here and changing the bug title, because I can reproduce a similar error (or the same one, not sure) in net/samba413 (4.13.0) as well as Samba-4.12.8. And I believe I have reproduction steps that are easier to simulate than what I originally described. I have further isolated the problem to what I believe is an issue in Samba's vfs_dirsort module. First, does anyone know how I can rebuild the Samba port with full debugging symbols turned on? Current backtrace dumps from the crashing processes are missing debug information. Getting that turned on and reproducing the crash would probably help a lot here. Steps to reproduce: Requirements: - Windows 10-based machine - 7-Zip 20.00 alpha x64 - Snort.org subscriber ruleset tar.gz archive (snortrules-snapshot-xxxxx.tar.gz) - Samba share on ZFS - 'dirsort' loaded in "vfs objects" Steps: - On the Windows machine, map a drive letter to the Samba share - Using 7-zip, open the snortrules-snapshot-xxxxx.tar.gz archive - Drag and drop the "rules" subfolder directly into the share - Attempt to double-click on the folder - Crash should be triggered (may have to repeat or F5 a bunch of times) As far as I can tell, some content in one of the Snort rule files may be a trigger, but I cannot work out if it's a specific file, combination of files, file sizes, number of files, etc. I tried stripping off any and all acls via 'setfacl -b *', and removed execute permissions via 'chmod -x *', but that has had no effect. I tried moving files elsewhere and refreshing the folder, but still couldn't isolate it to a specific file or files. After I gave up on that, I started removing vfs modules, starting with the zfsacl and freebsd ones, but that didn't work. After removing dirsort, however, I have been unable to reproduce the crash via the new method described here. I can reproduce the icon issue, but apparently without the crash described in my original comment. So likely, the crash issue is tied to something in the dirsort module on FreeBSD platforms, while the icon issue is something else. Fixing the crash is more important, so changing the bug to match that is best. I also suspect that the use of 7-zip to unpack the Snort rules archive is important. I tried unpacking that archive directly on the NAS machine's shell using tar zfx, and was unable to get it to crash via Samba afterward. When you drag and drop files from an archive to their destination, 7-zip will first extract to %TMPDIR% on the Windows host, then move the files to the final destination. Something in this process apparently sets up conditions that enable the crash to happen, but I cannot determine what these conditions are. Created attachment 219294 [details]
Samba config file for net/samba413
"hosts allow" and "workgroup" have been redacted. Everything else is as-is.
Created attachment 219295 [details]
Crash log snippet from net/samba413
One specific set of crash dump output when the problem is triggered. Multiple such dumps get generated when the error is reproduced, eventually flooding 'dmesg' out. And "foo" is the redacted name for the machine. Unlike the net/samba410 crash, the backtrace info is missing the symbol names, so it's impossible to work out exactly what happened.
Is this still a problem with net/samba416 or net/samba419 ? |