Netatalk 3.1.13 segfaults in afpd #175
Comments
Sure, I've just upgraded the system with the package Anyway, I'll come back here in a while once I can confirm the users can login and work as they did with 3.1.12. |
|
Forgot to say that since version 3.1.12 is no longer available on EPEL, the only way, on CentOS 7, to downgrade is downloading it from Koji: https://koji.fedoraproject.org/koji/buildinfo?buildID=1403661 |
|
With the package Since these messages were not present with the previous version, I've downgraded to 3.1.12 again. |
|
I've gone ahead and built 3.1.12 in my copr repo, to make it a little easier to downgrade. I'll announce that in redhat bugzilla as well. |
While there are known security issues in this release, 3.1.13 is not functionnal and segfault pretty fast. Netatalk should only be used in trusted local network anyway. https://sourceforge.net/p/netatalk/bugs/670/ https://sourceforge.net/p/netatalk/bugs/669/ Netatalk/netatalk#175 Work is ongoing and a fix is being tested. While here, add a fix to use perl Net::Socket::IP and make sure tracker3 is not picked up. Bump to be ahead of -stable.
|
I've just upgraded my server with the latest version: netatalk-3.1.13-3.el7. |
|
No errors and no problems appeared using the latest version. |
|
Great glad to hear! Thanks goes to @anodos325 for doing the hard part. I simply patched his PR against the 3.1.13 tarball. |
|
Okay. It's important to know that with this patchset the error handling for an AFP metadata xattr that fails to parse is different. Original code was to delete xattr and generate new one. Current behavior in this PR is to AFP_ASSERT(), which crashes netatalk and may generate corefile. The reason for this is so that we avoid removing xattr if people discover a new parsing bug (fail safe from user data standpoint), and give package maintainer the opportunity to see what went wrong. I presume that eventually this (the AFP_ASSERT()) can be removed before final merge / new release to restore original behavior (deleting xattr and generating new one). This does expose ability for malicious local user to basically DOS a path on the netatalk server by writing junk data to an AFP metadata xattr. I think this is an acceptable risk for what is WIP / pending PR while it continues to be tested. |
This commit backports pending PR, which solves segfaults: - Netatalk/netatalk#174 To fix issues with segfaults described here: - openwrt#18571 - Netatalk/netatalk#175 Signed-off-by: Šimon Bořek <[email protected]>
This commit backports pending PR, which solves segfaults: - Netatalk/netatalk#174 To fix issues with segfaults described here: - openwrt#18571 - Netatalk/netatalk#175 Signed-off-by: Šimon Bořek <[email protected]>
This commit backports pending PR, which solves segfaults: - Netatalk/netatalk#174 To fix issues with segfaults described here: - openwrt#18571 - Netatalk/netatalk#175 Signed-off-by: Šimon Bořek <[email protected]>
This commit backports pending PR, which solves segfaults: - Netatalk/netatalk#174 To fix issues with segfaults described here: - #18571 - Netatalk/netatalk#175 Signed-off-by: Šimon Bořek <[email protected]>
This commit backports pending PR, which solves segfaults: - Netatalk/netatalk#174 To fix issues with segfaults described here: - openwrt#18571 - Netatalk/netatalk#175 Signed-off-by: Šimon Bořek <[email protected]> (cherry picked from commit ab76857)
This commit backports pending PR, which solves segfaults: - Netatalk/netatalk#174 To fix issues with segfaults described here: - openwrt#18571 - Netatalk/netatalk#175 Signed-off-by: Šimon Bořek <[email protected]>
This commit backports pending PR, which solves segfaults: - Netatalk/netatalk#174 To fix issues with segfaults described here: - openwrt#18571 - Netatalk/netatalk#175 Signed-off-by: Šimon Bořek <[email protected]> (cherry picked from commit ab76857)
|
Hello, I'm not sure if this is still related to this issue, but I see those messages after upgrading to 3.1.13: Any idea? OS: CentOS 7 Linux |
|
@mikaku Can you please upgrade to 3.1.14 and try to reproduce your issue there? If it still persists, please file a new issue ticket. |
|
@rdmark Sure, you mean that one still in testing right? https://dl.fedoraproject.org/pub/epel/testing/7/x86_64/Packages/n/netatalk-3.1.14-3.el7.x86_64.rpm |
|
@mikaku you can upgrade to 3.1.14 today with a simple yum/dnf upgrade. 3.1.14 has been in fedora & epel repos since Jan 12. The latest 3.1.14-3 was pushed yesterday, to fix a CVE. It is not related to the issue you experiencing. |
|
If 3.1.14-3 is not necessary then my server is already using the 3.1.14: |
|
Since this issue is still occurring with 3.1.14, you may want to create a new issue and identify it as such, to get the developers attention. I just noticed release notes for 3.1.15 were just committed to master, so it looks like a new release is imminent. Don't know if that will help, but I'll build a new set of rpms once the release is made official. |
|
@mikaku Did the problematic volumes by any chance start out as netatalk2 volumes and then converted to netatalk3 at some point over the years? |
Hello,
After upgrading from 3.1.12 to 3.1.13 I'm seeing segmentation fault messages every time a user logs in:
OS: CentOS Linux 7.9
Kernel: 3.10.0-1160.59.1.el7.x86_64
Package: netatalk-3.1.13-1.el7.x86_64
Let me know if you need more information.
Thanks.
The text was updated successfully, but these errors were encountered: