Hi Gabriel, Any DOS implications are due to some loop in the client() code or the calling init scaffolding. The #FridgeArt isn't that robust, but let's assume it's in the client() routine instead. The log messages - really, anything at all - would be a huge help.
I'm looking at the patch, and I'm not sure it's not killing the persist behaviour. Have you seen this happen on a stock+systemd vtun install? I'm worried that the behaviour's restricted to some code hack that's not present on the upstream. Toss me a link to the project on fedora? I'd like to know more before 304 goes out. - bish > Hi, > > I maintain the vtun package in Fedora, and I just had a bug > opened against it (with potential security implications), pointing > at the following Debian bug report: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818489 > > Allegedly, under certain conditions, sending a SIGHUP to a client-mode > vtund process can peg the CPU, and generate large amounts of log data > (which is where the security angle comes from, I think). > > The Debian link above contains a patch as well. > > Is this something that could/should be applied upstream > (i.e., in sourceforge CVS) ? > > Thanks much, > --Gabriel >
0xB6187995.asc
Description: application/pgp-keys
------------------------------------------------------------------------------
_______________________________________________ VTun-devel mailing list VTun-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vtun-devel
