From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28646 invoked by alias); 1 Feb 2015 20:14:19 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 28619 invoked by uid 48); 1 Feb 2015 20:14:15 -0000 From: "max at cxib dot net" To: glibc-bugs@sourceware.org Subject: [Bug nis/17913] New: NIS+ Stack allocation Date: Sun, 01 Feb 2015 20:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nis X-Bugzilla-Version: 2.20 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: max at cxib dot net X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg00003.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17913 Bug ID: 17913 Summary: NIS+ Stack allocation Product: glibc Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: nis Assignee: unassigned at sourceware dot org Reporter: max at cxib dot net CC: kukuk at suse dot de Reference: https://sourceware.org/bugzilla/show_bug.cgi?id=17897 Hi, I've compared a _nss_nisplus_getservbyname_r() and _nss_nis_getservbyport_r() and in NIS+ implementation, there is no limit for stack allocation like in NIS implementation. NIS ------------------------------------- enum nss_status _nss_nis_getservbyport_r (int port, const char *protocol, struct servent *serv, char *buffer, size_t buflen, int *errnop) { char *domain; if (__glibc_unlikely (yp_get_default_domain (&domain))) return NSS_STATUS_UNAVAIL; /* If the protocol is given, we only need one query. Otherwise try first port/tcp, then port/udp and then fallback to sequential scanning of services.byname. */ const char *proto = protocol != NULL ? protocol : "tcp"; /* Limit protocol name length to the maximum size of an RPC packet. */ if (strlen (proto) > UDPMSGSIZE) <============================================ { *errnop = ERANGE; return NSS_STATUS_UNAVAIL; } do { /* key is: "port/proto" */ char key[sizeof (int) * 3 + strlen (proto) + 2]; <================ OK size_t keylen = snprintf (key, sizeof (key), "%d/%s", ntohs (port), proto); ------------------------------------- NIS+ ------------------------------------- enum nss_status _nss_nisplus_getservbyname_r (const char *name, const char *protocol, struct servent *serv, char *buffer, size_t buflen, int *errnop) { if (tablename_val == NULL) { __libc_lock_lock (lock); enum nss_status status = _nss_create_tablename (errnop); __libc_lock_unlock (lock); if (status != NSS_STATUS_SUCCESS) return status; } if (name == NULL || protocol == NULL) { *errnop = EINVAL; return NSS_STATUS_NOTFOUND; } size_t protocol_len = strlen (protocol); char buf[strlen (name) + protocol_len + 17 + tablename_len]; <======= NOK int olderr = errno; ------------------------------------- in one case, is checking the length, and the second is not. -- You are receiving this mail because: You are on the CC list for the bug.