From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21190 invoked by alias); 18 May 2009 06:48:47 -0000 Received: (qmail 21173 invoked by uid 22791); 18 May 2009 06:48:46 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 May 2009 06:48:40 +0000 Received: from sunsite.mff.cuni.cz (localhost.localdomain [127.0.0.1]) by sunsite.mff.cuni.cz (8.13.8/8.13.8) with ESMTP id n4I70vBu026685; Mon, 18 May 2009 09:00:57 +0200 Received: (from jakub@localhost) by sunsite.mff.cuni.cz (8.13.8/8.13.8/Submit) id n4I70vbb026683; Mon, 18 May 2009 09:00:57 +0200 Date: Mon, 18 May 2009 06:48:00 -0000 From: Jakub Jelinek To: Ulrich Drepper Cc: Glibc hackers Subject: [PATCH] Fix nscd_helper.c Message-ID: <20090518070057.GO16681@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00008.txt.bz2 Hi! Adding datalen in __nscd_cache_search is IMHO not correct, some databases contain mixed type of entries (group contains grp and initgr, hosts hst and ai responses, which have different datalen). Additionally some databases share one datahead with up to two hashentries and in __nscd_cache_search we want a safe upper bound for number of hash entries. So, IMHO the right computation is one hashentry and half of a datahead, without any payload (or with minimum of payloads, but that doesn't make a very big difference). Additionally, using sizeof (struct hashentry) in nscd client looks wrong to me. What if a 64-bit program using nscd client is run against 32-bit nscd? The last union in struct hashentry contains a pointer, if mempool_alloc allocates the hashentry at the very end of memory, the 64-bit client would consider it to be out of range. 2009-05-18 Jakub Jelinek * nscd/nscd_helper.c (__nscd_cache_search): Assume each entry in the hash chain needs one hashentry and half of datahead. Use offseof instead of sizeof for struct hashentry. diff --git a/nscd/nscd_helper.c b/nscd/nscd_helper.c index c09f008..bddf3d2 100644 --- a/nscd/nscd_helper.c +++ b/nscd/nscd_helper.c @@ -481,10 +481,12 @@ __nscd_cache_search (request_type type, const char *key, size_t keylen, ref_t trail = mapped->head->array[hash]; trail = atomic_forced_read (trail); ref_t work = trail; - size_t loop_cnt = datasize / (offsetof (struct datahead, data) + datalen); + size_t loop_cnt = datasize / (offsetof (struct hashentry, dellist) + + offsetof (struct datahead, data) / 2); int tick = 0; - while (work != ENDREF && work + sizeof (struct hashentry) <= datasize) + while (work != ENDREF + && work + offsetof (struct hashentry, dellist) <= datasize) { struct hashentry *here = (struct hashentry *) (mapped->data + work); ref_t here_key, here_packet; @@ -541,7 +543,7 @@ __nscd_cache_search (request_type type, const char *key, size_t keylen, return NULL; #endif - if (trail + sizeof (struct hashentry) > datasize) + if (trail + offsetof (struct hashentry, dellist) > datasize) return NULL; trail = atomic_forced_read (trailelem->next); Jakub