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/