From mdequenes at uperto.com Mon Jan 20 15:38:32 2014 From: mdequenes at uperto.com (Marc Dequenes) Date: Mon, 20 Jan 2014 16:38:32 +0100 Subject: [tac_plus] Patch for a crash when using long commands Message-ID: Coin, One of our clients had a bug wich seemed to happen only with long commands like: path 1 e1 15 tu12-au4 1 3 framing crc4 mapping-mode bit-async timeslots 1-9 10-18 19-27 (on CISCO routers, probably CRS) The child process crashed with: *** glibc detected *** /usr/bin/tac_plus: free(): invalid next size (fast): 0x000000001eea4d60 *** ======= Backtrace: ========= /lib64/libc.so.6[0x37aaa7230f] /lib64/libc.so.6(cfree+0x4b)[0x37aaa7276b] /usr/bin/tac_plus[0x40a205] /usr/bin/tac_plus[0x403af6] /usr/bin/tac_plus[0x40f2ea] /usr/bin/tac_plus[0x40fc24] /lib64/libc.so.6(__libc_start_main+0xf4)[0x37aaa1d994] /usr/bin/tac_plus[0x402939] I found an off-by-one mistake in the command buffer allocation (room for \0 was forgotten) and made a small patch to fix it. We are unable to reproduce since then. Regards. -- Marc Dequ?nes Consultant Devoteam Uperto/IdeOS -------------- next part -------------- A non-text attachment was scrubbed... Name: tacacs+_buffer_alloc_offbyone.patch Type: text/x-patch Size: 408 bytes Desc: not available URL: From heas at shrubbery.net Tue Jan 21 20:15:02 2014 From: heas at shrubbery.net (heasley) Date: Tue, 21 Jan 2014 20:15:02 +0000 Subject: [tac_plus] Patch for a crash when using long commands In-Reply-To: References: Message-ID: <20140121201502.GM6256@shrubbery.net> Mon, Jan 20, 2014 at 04:38:32PM +0100, Marc Dequenes: > Coin, > > One of our clients had a bug wich seemed to happen only with long commands like: > path 1 e1 15 tu12-au4 1 3 framing crc4 mapping-mode bit-async > timeslots 1-9 10-18 19-27 > (on CISCO routers, probably CRS) > > The child process crashed with: > *** glibc detected *** /usr/bin/tac_plus: free(): invalid next size > (fast): 0x000000001eea4d60 *** > ======= Backtrace: ========= > /lib64/libc.so.6[0x37aaa7230f] > /lib64/libc.so.6(cfree+0x4b)[0x37aaa7276b] > /usr/bin/tac_plus[0x40a205] > /usr/bin/tac_plus[0x403af6] > /usr/bin/tac_plus[0x40f2ea] > /usr/bin/tac_plus[0x40fc24] > /lib64/libc.so.6(__libc_start_main+0xf4)[0x37aaa1d994] > /usr/bin/tac_plus[0x402939] > > I found an off-by-one mistake in the command buffer allocation (room > for \0 was forgotten) and made a small patch to fix it. We are unable > to reproduce since then. I suspect you're just getting lucky. looking at that code, its adding 1 byte for each argument. the the space calculation appears to be excessive. the glib error would imply that the something overstepped bounds and mashed malloc bookkeeping data. so, can you tell me more about the device configuration, the tacacs daemon configuration and provide a backtrace from the core file? This would check that theory: Index: do_author.c =================================================================== --- do_author.c (revision 3626) +++ do_author.c (working copy) @@ -395,9 +395,12 @@ free(buf); return(NULL); } - strcat(buf, v); - if (i < (data->num_in_args - 1)) - strcat(buf, " "); + strncat(buf, v, len - 1); + len -= strlen(v); + if (i < (data->num_in_args - 1)) { + strncat(buf, " ", len - 1); + len -= 1; + } } return(buf); } > Regards. > > -- > Marc Dequ?nes > Consultant Devoteam Uperto/IdeOS > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: tacacs+_buffer_alloc_offbyone.patch > Type: text/x-patch > Size: 408 bytes > Desc: not available > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus