-
Notifications
You must be signed in to change notification settings - Fork 35.6k
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
fuzz: split FuzzedSock interface and implementation #21630
Conversation
Concept ACK Thanks for making |
Can the uninitialized read also happen in i2p? (The
|
review-only ACK d2e8d12 📧 Show signature and timestampSignature:
Timestamp of file with hash |
Right! Addressed in #21631. |
Consider adding
|
review ACK 841905b 🍰 Show signature and timestampSignature:
Timestamp of file with hash |
@practicalswift, I will do |
src/test/fuzz/util.cpp
Outdated
{ | ||
if (!m_fuzzed_data_provider.ConsumeBool()) { | ||
m_socket = fuzzed_data_provider.ConsumeIntegral<SOCKET>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not changed in this PR, but is there any scenario where we want m_socket != INVALID_SOCKET
here?
Otherwise I'd prefer going with INVALID_SOCKET
. Perhaps Sock::m_socket
could be default initialized to INVALID_SOCKET
. That should be a safe default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally we want the fuzzed socket's m_socket
to be != INVALID_SOCKET
, otherwise a code that does if (sock.Get() == INVALID_SOCKET)
will "misbehave" when mocked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vasild Oh, I didn't think about the possibility to peek at m_socket
via Get()
. But then I guess we want two cases: 1.) m_socket == INVALID_SOCKET
, and 2.) m_socket != INVALID_SOCKET
where m_socket
is a very high number which is unlikely to coincide with a real opened file descriptor?
The current code allows m_socket
to be set to low numbers such as 0
, 1
, 2
, 3
, etc which may be problematic :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps m_socket = fuzzed_data_provider.ConsumeIntegralInRange<SOCKET>(INVALID_SOCKET - 1, INVALID_SOCKET)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right! And we can do even better:
- add a method to check if the
Sock
object "owns" a socket, similar tostd::unique_ptr::operator bool()
so that callers don't doGet() == INVALID_SOCKET
. - Add wrapper methods for
getsockname()
,setsockopt()
,bind()
andlisten()
. That way more code will be mockable, but more importantly - then nobody would need to callSock::Get()
anymore so the value ofm_socket
will remain "hidden" within theSock
class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vasild Sounds good! Until we have that in place I think it makes sense to set m_socket
to very high numbers here to avoid nasty surprises :) The thought of random reads/writes to existing open file descriptors is a bit scary even if only from fuzzing code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Low fd values avoided in #21677.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add wrapper methods for ...
Done in #21700
|
1c1467f i2p: cancel the Accept() method if waiting on the socket errors (Vasil Dimov) Pull request description: If `Sock::Wait()` fails, then cancel the `Accept()` method. Not checking the return value may cause an uninitialized read a few lines below when we read the `occurred` variable. [Spotted](bitcoin/bitcoin#21630 (comment)) by MarcoFalke, thanks! ACKs for top commit: laanwj: Code review ACK 1c1467f practicalswift: cr ACK 1c1467f: patch looks correct and agree with laanwj that `[[nodiscard]]` can be taken in a follow-up PR :) Tree-SHA512: 57fa8a03a4e055999e23121cd9ed1566a585ece0cf68b74223d8c902804cb6890218c9356d60e0560ccacc6c8542a526356c226ebd48e7b299b4572be312d49b
1c1467f i2p: cancel the Accept() method if waiting on the socket errors (Vasil Dimov) Pull request description: If `Sock::Wait()` fails, then cancel the `Accept()` method. Not checking the return value may cause an uninitialized read a few lines below when we read the `occurred` variable. [Spotted](bitcoin#21630 (comment)) by MarcoFalke, thanks! ACKs for top commit: laanwj: Code review ACK 1c1467f practicalswift: cr ACK 1c1467f: patch looks correct and agree with laanwj that `[[nodiscard]]` can be taken in a follow-up PR :) Tree-SHA512: 57fa8a03a4e055999e23121cd9ed1566a585ece0cf68b74223d8c902804cb6890218c9356d60e0560ccacc6c8542a526356c226ebd48e7b299b4572be312d49b
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsNo conflicts as of last run. |
Move the `FuzzedSock`'s implementation from `src/test/fuzz/util.h` to `src/test/fuzz/util.cpp`. A separate interface and implementation make the code more readable for consumers who don't need to (better not) know the implementation details.
The former is shorter and ends up with a "random" bool anyway.
|
cr ACK 549c82a: patch looks correct and touches only |
re-ACK 549c82a only change is rebase 🎬 Show signature and timestampSignature:
Timestamp of file with hash |
(this is a followup from #21617)