Date: Wed, 28 May 2003 15:02:51 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: atm@freebsd.org Subject: bug in netinet/if_atm.c Message-ID: <20030528145244.E614@beagle.fokus.fraunhofer.de>
next in thread | raw e-mail | index | archive | help
Hi, it seems I have found a bug in the interaction between the routing code and the NATM stuff. The problem occurs when adding a PVC for IP fails in the ioctl handler of the ATM driver. This handler is called via the rtrequest member of the interface address while processing RTM_ADD. This handler has no means to return an error to the generic routing code, so it executes an RTM_DELETE to delete the failed route. It seems that after returning from the rtrequest handler the RTM_ADD code is now accessing an invalid route pointer. I get diagnostic messages and panics that memory was changed after beeing freed. The following patch just removes the call to rtrequest(RTM_DELETE, ...). This means, that the route is in the routing table even if the ioctl in the driver has failed. This just means, that the driver will drop all packets and the route will not function. While this is not ideal, it is clearly better than panicking. Could someone with insight into the routing code have a lock at this and tell me whether the patch is ok? harti Index: if_atm.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/if_atm.c,v retrieving revision 1.11 diff -u -r1.11 if_atm.c --- if_atm.c 21 May 2002 18:52:24 -0000 1.11 +++ if_atm.c 28 May 2003 12:52:41 -0000 @@ -170,8 +170,6 @@ rt->rt_flags &= ~RTF_LLINFO; } #endif - rtrequest(RTM_DELETE, rt_key(rt), (struct sockaddr *)0, - rt_mask(rt), 0, (struct rtentry **) 0); break; case RTM_DELETE: -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030528145244.E614>