Hi,

It's been a while since we published the patches and since this issue has
been assigned a CVE ID. Do you still plan to check/apply the patches?

--
| Evgeny Uskov  | HLL l QRATOR
| mob.: +7 916 319 33 20
| skype: evgeny_uskov
| mailto: [email protected]
| visit: www.qrator.net

On Tue, May 17, 2016 at 9:59 PM, Florian Weimer <[email protected]> wrote:

> Donald and all,
>
> what is the status here?  Are t he patches good?
>
> Distributions have begun to issue security errata with these patches,
> even though I understand they have not been fully reviewed.
>
> Thanks,
> Florian
>
> * Donald Sharp:
>
> > 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
>
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to