From owner-svn-src-stable-10@freebsd.org Sat Feb 4 15:45:52 2017 Return-Path: Delivered-To: svn-src-stable-10@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D016DCD03D8; Sat, 4 Feb 2017 15:45:52 +0000 (UTC) (envelope-from ngie@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CD4E84F; Sat, 4 Feb 2017 15:45:52 +0000 (UTC) (envelope-from ngie@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v14FjpEY048453; Sat, 4 Feb 2017 15:45:51 GMT (envelope-from ngie@FreeBSD.org) Received: (from ngie@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v14FjpRP048452; Sat, 4 Feb 2017 15:45:51 GMT (envelope-from ngie@FreeBSD.org) Message-Id: <201702041545.v14FjpRP048452@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ngie set sender to ngie@FreeBSD.org using -f From: Ngie Cooper Date: Sat, 4 Feb 2017 15:45:51 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: svn commit: r313201 - stable/10/contrib/bsnmp/lib X-SVN-Group: stable-10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable-10@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for only the 10-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:45:52 -0000 Author: ngie Date: Sat Feb 4 15:45:51 2017 New Revision: 313201 URL: https://svnweb.freebsd.org/changeset/base/313201 Log: MFC r311263: Use calloc instead of malloc with buffers in snmp_{recv,send}_packet This doesn't fix the issue noted in the PR, but at the very least it cleans up the error so it looks a bit more sane, and in the event that bsnmp did wander off into the weeds, the likelihood of it crashing with more sensible output is greater, in my opinion MFC counter set high so I have enough time to resolve the real underlying bug in bsnmpwalk PR: 215721 Modified: stable/10/contrib/bsnmp/lib/snmpclient.c Directory Properties: stable/10/ (props changed) Modified: stable/10/contrib/bsnmp/lib/snmpclient.c ============================================================================== --- stable/10/contrib/bsnmp/lib/snmpclient.c Sat Feb 4 15:45:39 2017 (r313200) +++ stable/10/contrib/bsnmp/lib/snmpclient.c Sat Feb 4 15:45:51 2017 (r313201) @@ -1234,7 +1234,7 @@ snmp_send_packet(struct snmp_pdu * pdu) struct asn_buf b; ssize_t ret; - if ((buf = malloc(snmp_client.txbuflen)) == NULL) { + if ((buf = calloc(1, snmp_client.txbuflen)) == NULL) { seterr(&snmp_client, "%s", strerror(errno)); return (-1); } @@ -1259,7 +1259,7 @@ snmp_send_packet(struct snmp_pdu * pdu) } free(buf); - return pdu->request_id; + return (pdu->request_id); } /* @@ -1355,7 +1355,7 @@ snmp_receive_packet(struct snmp_pdu *pdu socklen_t optlen; #endif - if ((buf = malloc(snmp_client.rxbuflen)) == NULL) { + if ((buf = calloc(1, snmp_client.rxbuflen)) == NULL) { seterr(&snmp_client, "%s", strerror(errno)); return (-1); }