misc/95002: hash db source code has a bug which prevents using
cross-platform data base
Stephane Sudre
ssudre at intego.com
Mon Mar 27 13:10:13 UTC 2006
>Number: 95002
>Category: misc
>Synopsis: hash db source code has a bug which prevents using cross-platform data base
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Mar 27 13:10:11 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator: Stephane Sudre
>Release: Mac OS X
>Organization:
>Environment:
Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc
>Description:
Project: Libc
Folder: db
File: hash_page.c
Function: __put_page
Let's imagine you have a data base created on a BIG_ENDIAN system with the lorder flag set to 0 on creation and you're updating it on a LITTLE_ENDIAN system.
The lorder for the file as read on the LITTLE_ENDIAN system is 4321 (BIG_ENDIAN) so when you call __put_page, you are entering the case:
hashp->LORDER != BYTE_ORDER)
While the swap operation is perfect to write the data base on disk with _write, the current code is leading to a corruption of the data base because the buffer is not swapped back after writing.
>How-To-Repeat:
Create a hash data base on a PPC system.
Open this data base on a i386 system.
Update this data base with some put calls and then call sync twice.
=> The data base is corrupted.
>Fix:
AFAIK, the fix is to swap back buffer p with something like this after the call to _write (and probably also when _write call fails):
if (hashp->LORDER != BYTE_ORDER)
{
if (is_bitmap) {
for (i = 0; i < cached_max; i++)
M_32_SWAP(((int *)p)[i]);
} else {
for (i = 0; i <= cached_max; i++)
M_16_SWAP(((u_int16_t *)p)[i]);
}
}
where cached_max is the cached value of max computed previously in __put_page.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list