Adnan Khan

The use case I'm thinking of is for fuzzing more mature applications where simply finding a single crash would be valuable.

Sounds good! There are a few other things I ran into that could be changed such as the OpenProcess call failing in the attach case after the named pipe connection...

@nicocha30 I've spent a few hours trying to hunt this down. It looks like the panic happens because the UDP forwarder endpoint tried to read the network header from the...

I'm noticing that while the Windows proxy code has a call to `stack.NewPacketBuffer`, the Linux code uses the gvisor tun and fdbased packages. The actual call to create the PacketBuffer...

I added the following "hack" to `stack.go` in the handler that is passed to udp.NewForwarder, and it prevented the crash: ``` ptr_struct := unsafe.Pointer(request) ptr_struct = unsafe.Pointer(uintptr(ptr_struct) + uintptr(56)) ptrTobuf...

@virusvfv stack.PacketBufferPtr refers to the PacketBufferPtr object defined in https://github.com/google/gvisor/blob/master/pkg/tcpip/stack/packet_buffer.go, within the `stack` gvisor package. I forgot to mention that in my attempts to fix I switched the gvisor to...

@nicocha30 The "hack" code? No, just Linux x64. It definitely would need to be improved in order to be more generic (also not sure if the struct size would be...

I made a PR with the "temporary fix" that should prevent the crash until the root cause can be identified and fixed. https://github.com/nicocha30/ligolo-ng/pull/28

Wow, this is awesome; pretty cool that Google fixed it!

So in summary to find issues of this class one should look for the following? `pull_request_target` on the `labeled` trigger only + `actions/checkout` with `ref: ${{ github.event.pull_request.head.ref }}` and `repository:...