II. Problem Description

A check did not test both the dnode itself and its data for dirtiness. This provides a very small window of time while a file is being modified where the dirtiness check can falsely report that the dnode is clean. If this happens a hole may incorrectly be reported where data was written.

III. Impact

If an access occurs while a file is being modified and a hole is incorrectly reported, the data may instead be interpreted as zero bytes. Any application which checks for holes may be affected by this issue; if this occurs during a file copy it will result in a corrupt copy that retains the incorrect data. Note that the source file remains intact (a subsequent read will return the correct data).

IV. Workaround

Setting the vfs.zfs.dmu_offset_next_sync sysctl to 0 disables forcing TXG sync to find holes. This is an effective workaround that greatly reduces the likelihood of encountering data corruption, although it does not completely eliminate it. Note that with the workaround holes will not be reported in recently dirtied files. See the zfs(4) man page for more information of the impact of this sysctl setting.

The workaround should be removed once the system is updated to include the fix described in this notice.