systemd-resolved double free or corruption #3484
Comments
poettering
added
bug 🐛
…more dns_transaction_maybe_restart() is supposed to return 1 if the the transaction has been restarted and 0 otherwise. dns_transaction_process_dnssec() relies on this behaviour. Before this change in case of restart we'd call dns_transaction_go() when restarting the lookup, returning its return value unmodified. This is wrong however, as that function returns 1 if the transaction is pending, and 0 if it completed immediately, which is a very different set of return values. Fix this, by always returning 1 on redirection. The wrong return value resulted in all kinds of bad memory accesses as we might continue processing a transaction that was redirected and completed immediately (and thus freed). This patch also adds comments to the two functions to clarify the return values for the future. Most likely fixes: systemd#2942 systemd#3475 systemd#3484
|
I posted PR #3553 now that hopefully fixes this bug, but it's not fully clear to me if it is. I'd appreciate if you could test this and check if this makes the issue go away for you. If not, please file new stacktraces, with this patch applied. Thanks! |
…more (#3553) dns_transaction_maybe_restart() is supposed to return 1 if the the transaction has been restarted and 0 otherwise. dns_transaction_process_dnssec() relies on this behaviour. Before this change in case of restart we'd call dns_transaction_go() when restarting the lookup, returning its return value unmodified. This is wrong however, as that function returns 1 if the transaction is pending, and 0 if it completed immediately, which is a very different set of return values. Fix this, by always returning 1 on redirection. The wrong return value resulted in all kinds of bad memory accesses as we might continue processing a transaction that was redirected and completed immediately (and thus freed). This patch also adds comments to the two functions to clarify the return values for the future. Most likely fixes: #2942 #3475 #3484
|
OK, we had some positive feedback on #3553 now and it got merged, closing this one hence. Should you be able to reproduce your issue with that PR applied, please reopen. |
|
I confirm the problem doesn't happen anymore with the #3553 patch applied. |
|
I'm still having these errors, is there any way to confirm the problem is from an outdated distro image? Or the scaleway server or whatever it is. I'm getting these errors on Arch Linux ARM (Scaleway C1 server), the image is outdated (from december 2015) and I just upgraded the system (including systemd 231). Any help? Thanks. |
https://github.com/scaleway/image-archlinux/issues/36
This is not the same. You should update your unit file: https://github.com/scaleway/image-archlinux/blob/master/patches/etc/systemd/system/systemd-resolved.service Should be: |
|
That solved the problem. Thanks! |
|
I had a similar issue on a clean install of Ubuntu 17.01 where the systemd-resolved would fail to start. |
Submission type
systemd version the issue has been seen with
230
Used distribution
Gentoo
In case of bug report: Unexpected behaviour you saw
Remarks
DNSSEC=false + reboot solve the problem.
I see more than one error in this log:
I don't know if they are related.
The text was updated successfully, but these errors were encountered: