Subject: Re: PR/37236 CVS commit: src/usr.sbin/rpc.lockd
To: None <gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,>
From: Matthias Scheler <tron@zhadum.org.uk>
List: netbsd-bugs
Date: 11/04/2007 19:55:04
The following reply was made to PR bin/37236; it has been noted by GNATS.

From: Matthias Scheler <tron@zhadum.org.uk>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: PR/37236 CVS commit: src/usr.sbin/rpc.lockd
Date: Sun, 4 Nov 2007 19:54:37 +0000

 On Sun, Nov 04, 2007 at 07:52:50PM +0000, Matthias Scheler wrote:
 > The reason is heap corruption:
 > 
 > (gdb) print lcklst_head
 > $2 = {lh_first = 0x8b030210}
 > (gdb) print *(struct file_lock *)0x8b030210
 > Cannot access memory at address 0x8b030210
 > (gdb) print hostlst_head
 > $3 = {lh_first = 0x76b5bb51}
 > (gdb) print *(struct host *)0x76b5bb51
 > Cannot access memory at address 0x76b5bb51
 > 
 > This rules out the theory about a race condition. These pointers are
 > completely invalid.
 
 I hope that I found the problem. From "lock_proc.c":
 
 static struct sockaddr_storage clnt_cache_addr[CLIENT_CACHE_SIZE];
 
 [...]
         /* Success - update the cache entry */
         clnt_cache_ptr[clnt_cache_next_to_use] = client;
         memcpy(&clnt_cache_addr[clnt_cache_next_to_use], host_addr,
             host_addr->sa_len);
         clnt_cache_time[clnt_cache_next_to_use] = time_now.tv_sec;
         if (++clnt_cache_next_to_use > CLIENT_CACHE_SIZE)
                 clnt_cache_next_to_use = 0;
 [...]
 
 rpc.lockd(8) will happily overflow the clnt_cache_addr array by one.
 
 	Kind regards
 
 -- 
 Matthias Scheler                                  http://zhadum.org.uk/