Date: Sat, 24 Nov 2018 12:53:32 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 233306] panic when using userppp Message-ID: <bug-233306-227-2JHSO9ozr6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-233306-227@https.bugs.freebsd.org/bugzilla/> References: <bug-233306-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233306 lenzi.sergio@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199339|0 |1 is obsolete| | --- Comment #3 from lenzi.sergio@gmail.com --- Created attachment 199511 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D199511&action= =3Dedit remove code that panics the system due to invalid memory access The panic happens when the code: both i386 and amd64 info.rti_info[RTAX_IFP] =3D rt->rt_ifp->if_addr->ifa_addr; at /usr/src/sys/net/rtsock.c near line 1568 the code tries to access rt->rt_ifp->if_addr->ifa_addr, but because rt->rt_ifp points to an already freed memory, and the pointer is NOT NULL, probably because the free code d= oes not nulls the pointer. or a race condition in the code, the system panics at page fault in kernel mode The patch removes the line from the rtsock.c for a while until some guru tr= acks the race condition or fixes the pointer to a null value after rt->rt_ifp is freed and so a test can be done.. the server in test holds many (100+) pppoi connections that changes every t= ime, the server runs routed with flags=3D-s so the route tables are stressed in add/delete routes all the time... sometimes it panics in seconds, sometimes after hours... Now with this patch, it is working 24/7 for some days... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233306-227-2JHSO9ozr6>