comparison fuzz/fuzz-common.c @ 1785:9026f976eee8

fuzz: work around fuzz_connect_remote() limitations
author Matt Johnston <matt@ucc.asn.au>
date Sun, 06 Dec 2020 21:27:25 +0800
parents a6da10ac64b5
children a3b39df57c8b
comparison
equal deleted inserted replaced
1784:94323a20e572 1785:9026f976eee8
236 236
237 237
238 struct dropbear_progress_connection *fuzz_connect_remote(const char* UNUSED(remotehost), const char* UNUSED(remoteport), 238 struct dropbear_progress_connection *fuzz_connect_remote(const char* UNUSED(remotehost), const char* UNUSED(remoteport),
239 connect_callback cb, void* cb_data, 239 connect_callback cb, void* cb_data,
240 const char* UNUSED(bind_address), const char* UNUSED(bind_port)) { 240 const char* UNUSED(bind_address), const char* UNUSED(bind_port)) {
241 /* This replacement for connect_remote() has slightly different semantics
242 to the real thing. It should probably be replaced with something more sophisticated.
243 It calls the callback cb() immediately rather than
244 in a future session loop iteration with set_connect_fds()/handle_connect_fds().
245 This could cause problems depending on how connect_remote() is used. In particular
246 the callback can close a channel - that can cause use-after-free. */
241 char r; 247 char r;
242 genrandom((void*)&r, 1); 248 genrandom((void*)&r, 1);
243 if (r & 1) { 249 if (r & 1) {
244 int sock = wrapfd_new_dummy(); 250 int sock = wrapfd_new_dummy();
245 cb(DROPBEAR_SUCCESS, sock, cb_data, NULL); 251 cb(DROPBEAR_SUCCESS, sock, cb_data, NULL);