Hey Gabe, An array of RHBZs; yeesh! But they still look to stem from the one issue reported on the debian fork, which is itself without any assessment. And the CVE application jammed after review.
Caution's good, to be sure, and the patch is appealingly simple. But I'm not sure its affect is so wide, and I want to leave it as-is unless we can get something closer to stock source. https://sourceforge.net/p/vtun/bugs/58/ . I'm going to push 304, I think. Then let's talk about shrinking the aftermarket, if the $DayJob lets ya (and I understand only so well!) - bish eRancher by day, Janitor and Fishmonger by night. Gabriel L. Somlo wrote: > Bish, > > check out https://bugzilla.redhat.com/show_bug.cgi?id=1319858 > > (particularly the way the reporter closed the bug at the very end -- > after I already applied the out-of-tree patch, out of "an excess of > caution" :) > > If the links in the closing message confirm your suspicion (that this > is an unlikely thing to become a *real* problem), that's OK with me. > This all happened after I had originally emailed you, and meanwhile > $DAYJOB caught up with me and I stopped closely following the issue... > > I'd be happy to upgrade to 3.0.4 and drop all current "aftermarket" > patches when you finally get around to doing a release. > > Thanks again for following up, > --Gabe > > On Sat, Sep 17, 2016 at 04:48:33PM -0400, bishop wrote: >> 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 >>> > >> pub 1024D/B6187995 2008-07-25 Bishop (LC957) <bis...@platypus.bc.ca> >> uid Bishop Clark (hpas) <bishop.cl...@hpas.ca> >> uid Bishop Clark <bishopo...@gmail.com> >> uid Bishop Clark <bishop.cl...@gmail.com> >> uid Bishop Clark (old work) >> <bishop.cl...@hpadvancedsolutions.com> >> uid Bishop Clark (old work) <bishop.cl...@hpas.ca> >> uid Bishop Clark (old work) >> <bcl...@halogensoftware.com> >> uid Bishop Clark (old work) >> <bishop.cl...@gov.bc.ca> >> uid Bishop Clark (work) >> <bishop.cl...@hpadvancedsolutions.com> >> uid Bishop Clark (old work) <bish...@sco.com> >> sub 1024g/F0E863B7 2008-07-25 [expires: 2018-06-11] >> sub 4096R/0DF6635B 2016-08-27 [expires: 2021-08-26] >> sub 4096R/400FB98C 2016-08-27 [expires: 2021-08-26] ------------------------------------------------------------------------------ _______________________________________________ VTun-devel mailing list VTun-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vtun-devel
