This was discovered by midipix (@mpixorg) via heap-based overflow in ssh client with a select implementation that writes the whole fd_set, which seems to be conforming behavior.
-
-
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Does this not work? I thought this was the workaround used if your fd number was higher than would fit in a fd_set?
-
That's not valid usage; the args must be null or point to objects of type fd_set. A hardened implementation will trap on nfds>FD_SETSIZE since it's UB.
-
If you really want to *try* using higher numbers and hope it works, you really need to allocate an array of fd_set objects (rounded up to whole objects) rather than partial ones, and apply the FD_*() macros to the right element of the array. But there's no guarantee it'll work.
-
What layer of the stack defines this as UB? A while back a friend and I looked at this and confirmed that most "traditional Unix-like or inspired" (Linux, macOS, and some BSDs) just use bitfields of various shapes for fd_set and work just fine with larger/smaller ones.
-
Violation of a "shall" in the description of select's interface contract.
-
Note that there's no specification of the layout/order of bits in the fd_set so the low bits could be at the end of it.
-
I know this part. We were making syscalls directly and had slightly different codepaths for all the platforms we supported.
-
The syscall APIs are not the same as the Posix APIs.
End of conversation
New conversation -
-
-
Where does this occur? fd_sets in OpenSSH should be allocated as multiples of (NFDBITS*sizeof(fd_mask)) for this very reason.
-
It's right in channel.c but wrong in packet.c.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.