From nobody@FreeBSD.org  Mon Mar 27 13:04:31 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6F42316A438
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 27 Mar 2006 13:04:31 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D76D243D48
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 27 Mar 2006 13:04:30 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k2RD4Tcf057965
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 27 Mar 2006 13:04:29 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k2RD4T8I057962;
	Mon, 27 Mar 2006 13:04:29 GMT
	(envelope-from nobody)
Message-Id: <200603271304.k2RD4T8I057962@www.freebsd.org>
Date: Mon, 27 Mar 2006 13:04:29 GMT
From: Stephane Sudre <ssudre@intego.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: hash db source code has a bug which prevents using cross-platform data base
X-Send-Pr-Version: www-2.3

>Number:         95002
>Category:       bin
>Synopsis:       [libc] 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:  Mon Dec 29 18:58:42 UTC 2008
>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:
