On Thu, May 25, 2023 at 02:20:37PM +0100, Stuart Henderson wrote: > On 2023/05/25 15:06, Claudio Jeker wrote: > > sthen@ reported a bgpd SE crash to me and after inspection of the report > > it looks like he managed to trigger a mistake in session_process_msg(). > > When for example a NOTIFICATION message is received then the state change > > clears the rbuf. Now normally the for loop starts over afterwards and the > > if (p->rbuf == NULL) at the top causes the function to return. > > In his case the peer had enough messages queued that the if (++processed > > > MSG_PROCESS_LIMIT) limit triggered after the NOTIFICATION was processed. > > This hits a break from the for loop and the code at the end of the > > function adjusting the rbuf trips over the NULL rbuf pointer. > > > > This can be fixed in many ways, I decided to just check at the end of the > > loop that rbuf is still valid. > > Thanks for looking into this. OK. > > > Triggering this bug is not trivial so it is hard test but the problem is > > obvious. > > indeed, I don't think I have hit this one at all before. > > Running sessions over routes maintained by ospf6d seems a fairly > good way to trigger a number of issues ;)
I do run ospf6d on some systems but it seems my setup is too small to trigger all those strange issues. :( -- :wq Claudio
