Repository navigation
fix(hutils): capget writing past its buffer in TunAllowed - #157
Merged
Merged
Conversation
TunAllowed asks for LINUX_CAPABILITY_VERSION_3, for which the kernel always writes two CapUserData (caps 0-31 and 32-63, 24 bytes), but it passed a single one (12 bytes), so the kernel wrote 12 bytes past it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TunAllowed()(desktop Linux) callscapgetwithLINUX_CAPABILITY_VERSION_3and a singleunix.CapUserData. For versions 2 and 3 the kernel always writes two__user_cap_data_struct(capabilities 0-31 and 32-63, 24 bytes; seecapget(2)), so it writes 12 bytes pastdata, onto the stack.The second struct isn't empty in practice. For a process with full capabilities it holds
Effective:511, for capabilities 32-40 (I checked this through the same call in rootlesskit, rootless-containers/rootlesskit#658).I haven't seen this crash Hiddify; the file is
linux && !android, so Android isn't affected. The same code in Xray-core's WireGuard client (XTLS/Xray-core#7274) corrupted a saved return address on 32-bit ARM and crashed every time, so it's worth fixing.The fix passes
[2]unix.CapUserDataand readsdata[0].CAP_NET_ADMINis 12, so the result doesn't change.Tested:
gofmtis clean, andgo vet ./v2/hutils/passes for linux/amd64, arm64 and arm. I also ran the patchedTunAllowed()on its own. It returnsfalseunprivileged andtrueinsideunshare -rn, where the process hasCAP_NET_ADMIN.