Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 3 Apr 2016 09:53:11 -0400
From: Kash Pande <kash@...pleback.net>
To: oss-security@...ts.openwall.com
Subject: OpenZFS (Linux, FreeBSD, illumos) fails to transmit holes

This needs CVE - It seems best to have a single CVE for OpenZFS rather
than one for each distribution.

https://github.com/openzfs/openzfs/pull/37

    In certain circumstances, "zfs send -i" (incremental send) can produce a
    stream which will result in incorrect sparse file contents on the
    target.

    The problem manifests as regions of the received file that should be
    sparse (and read a zero-filled) actually contain data from a file that
    was deleted (and which happened to share this file's object ID).

    Note: this can happen only with filesystems (not zvols, because they do
    not free (or reuse) object IDs).

    Note: This can happen only if, since the incremental source (FromSnap),
    a file was deleted and then another file was created, and the new file
    is sparse (i.e. has areas that were never written to and should be
    implicitly zero-filled).

    We suspect that this was introduced by 4370 (applies only if hole_birth
    feature is enabled), and made worse by 5243 (applies if hole_birth
    feature is disabled, and we never send any holes).

    The bug is caused by the hole birth feature. When an object is deleted
    and replaced, all the holes in the object have birth time zero. However,
    zfs send cannot tell that the holes are new since the file was replaced,
    so it doesn't send them in an incremental. As a result, you can end up
    with invalid data when you receive incremental send streams. As a
    short-term fix, we can always send holes with birth time 0 (unless it's
    a zvol or a dataset where we can guarantee that no objects have been
    reused).



Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ