Hi, This issue has been assigned the name CVE-2016-4049. Further security advisories can use this ID as a reference.
-- | Evgeny Uskov | HLL l QRATOR | mob.: +7 916 319 33 20 | skype: evgeny_uskov | mailto: [email protected] | visit: www.qrator.net On Wed, Feb 3, 2016 at 3:24 PM, Donald Sharp <[email protected]> wrote: > Evgeny - > > It's on the list of patches to be applied for the next round. > > donald > > On Wed, Feb 3, 2016 at 7:16 AM, Evgeny Uskov <[email protected]> wrote: > >> Hi, >> >> Any news regarding the patching process? >> >> -- >> | Evgeny Uskov | HLL l QRATOR >> | mob.: +7 916 319 33 20 >> | skype: evgeny_uskov >> | mailto: [email protected] >> | visit: www.qrator.net >> >> On Mon, Jan 25, 2016 at 5:55 PM, Evgeny Uskov <[email protected]> wrote: >> >>> Paul, >>> >>> Please see the attached files created with "git format-patch". >>> >>> Regarding the chunk with bgp_dump_obuf creation, it was done >>> intentionally with the following purpose. >>> The key idea of the patch is that if the portion of data (i.e. the RIB >>> entry corresponding to the prefix) is greater than the remaining space in >>> the current MRT record, then we finalize the current record and put this >>> portion of data to the next record. The function writing the portion of >>> data (bgp_dump_routes_attr) does not perform size checking, and hence we >>> decided to implement the logic above in the following way. >>> 1) We increased the max size of bgp_dump_obuf; >>> 2) after each portion of data we compare the current data size >>> with BGP_MAX_PACKET_SIZE + BGP_DUMP_MSG_HEADER + BGP_DUMP_HEADER_SIZE. If >>> the data size is greater than this value, then we finalize the record with >>> all the RIB entries except this last one (which does not fit to max packet >>> size), and the last RIB entry goes to the next data portion. >>> >>> The size of bgp_dump_obuf in this case should be at least >>> BGP_MAX_PACKET_SIZE + BGP_DUMP_MSG_HEADER + BGP_DUMP_HEADER_SIZE + (max >>> size of the RIB entry). In the patches attached to this letter we removed >>> the magic constant 0x4000, set the size in the following way: >>> >>> - bgp_dump_obuf = stream_new (BGP_MAX_PACKET_SIZE + BGP_DUMP_MSG_HEADER >>> - + BGP_DUMP_HEADER_SIZE); >>> + bgp_dump_obuf = stream_new ((BGP_MAX_PACKET_SIZE << 1) >>> + + BGP_DUMP_MSG_HEADER + >>> BGP_DUMP_HEADER_SIZE); >>> >>> I.e. we added one extra BGP_MAX_PACKET_SIZE which should be enough to >>> contain any possible RIB entry. >>> >>> -- >>> | Evgeny Uskov | HLL l QRATOR >>> | mob.: +7 916 319 33 20 >>> | skype: evgeny_uskov >>> | mailto: [email protected] >>> | visit: www.qrator.net >>> >>> On Mon, Jan 25, 2016 at 4:16 PM, Paul Jakma <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> On Mon, 25 Jan 2016, Evgeny Uskov wrote: >>>> >>>> The easiest way to eliminate the problem is to create multiple MRT >>>>> records >>>>> if there is too much data for a prefix. Please see the attached file >>>>> dump_fix.patch implementing such solution. >>>>> >>>>> >>>>> Finally, we have noticed a typo in the description of "dump bgp" >>>>> command. >>>>> Please see the attached file comment_fix.patch. >>>>> >>>> >>>> Nice. Thanks! >>>> >>>> One thing, could you supply it as a git commit, or otherwise just >>>> supply a commit message. >>>> >>>> Also, did you intend to submit this chunk? If yes, what's the purpose? >>>> >>>> - bgp_dump_obuf = stream_new (BGP_MAX_PACKET_SIZE + BGP_DUMP_MSG_HEADER >>>> - + BGP_DUMP_HEADER_SIZE); >>>> + bgp_dump_obuf = stream_new (0x4000); >>>> >>>> regards, >>>> -- >>>> Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A >>>> Fortune: >>>> Our country has plenty of good five-cent cigars, but the trouble is >>>> they charge fifteen cents for them. >>>> >>> >>> >> >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> > >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
