-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Out-of-bounds write in parseBenc #3591
Labels
Comments
If you're satisfied with both the test and the fix, I'll submit a PR. |
A more lax approach: diff --git a/libtransmission/torrent-metainfo.cc b/libtransmission/torrent-metainfo.cc
index cec210d..6470590 100644
--- a/libtransmission/torrent-metainfo.cc
+++ b/libtransmission/torrent-metainfo.cc
@@ -457,7 +457,10 @@ struct MetainfoHandler final : public transmission::benc::BasicHandler<MaxBencDe
{
auto const n = std::size(value) / sizeof(tr_sha1_digest_t);
tm_.pieces_.resize(n);
- std::copy_n(std::data(value), std::size(value), reinterpret_cast<char*>(std::data(tm_.pieces_)));
+ std::copy_n(
+ std::data(value),
+ n * sizeof(tr_sha1_digest_t),
+ reinterpret_cast<char*>(std::data(tm_.pieces_)));
tm_.pieces_offset_ = context.tokenSpan().first;
}
else if (pathStartsWith(PieceLayersKey)) This simply ignores the excess bytes. |
At a minimum we should log m error. I’m inclined to say refuse to parse a torrent with the wrong length since it’s likely a sign of a corrupt torrent. That array should always be cleanly divisible by 20. I’d be fine with a PR that checks this to safeguard against corrupt torrents. |
guidovranken
added a commit
to guidovranken/transmission
that referenced
this issue
Aug 6, 2022
ckerr
pushed a commit
to guidovranken/transmission
that referenced
this issue
Aug 9, 2022
ckerr
pushed a commit
that referenced
this issue
Aug 9, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This code:
transmission/libtransmission/torrent-metainfo.cc
Lines 458 to 461 in 4bc1589
Allocates enough room for
n
elements, but then proceeds to copyn
elements AND the remaining data. So ifstd::size(value)
is 21 (andsizeof(tr_sha1_digest_t)
is 20), then it allocates 1 element (= 20 bytes), and copy 21 bytes to it.Test for this issue:
Potential fix (it addresses the issue, but I don't know if it's compliant with the relevant specs):
The text was updated successfully, but these errors were encountered: