-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crash when acquiring lock in 3.3.23 #12156
Comments
is this already fixed by #12106? |
The fix is in 3.5 and 3.4.10. I don't think it was backported to 3.3.x branch. Can you updated etcd to 3.4 or downgrade protobuf version used together with 3.3 ? |
I cannot immediately upgrade to 3.4. I am using your binary builds of 3.3; if you release a new 3.3 with a an older protobuf, then I'll gladly use it... |
I confirm hitting the same bug. In our case, 3.3.x is used because of kubespray deployment of etcd. For the time being, I have downgraded to 3.3.22 which seems to work fine. |
same issue in v3.3.23 with commit id
|
3.3.23 has security fix for CVE-2020-15106 and CVE-2020-15112, could we backport #12000 (#12106) to 3.3? cc @YoyinZyc |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
Attempting to acquire a named lock in a 3.3.23 cluster results in a panic of the leader:
Simply running
etcdctl --endpoints http://hostname:port lock /test ls
is enough to trigger this.The text was updated successfully, but these errors were encountered: