this bug report will now be limited to things that are presumed to be
fixed by 2.2.2 or 2.1.14, or the dirty dnode patch backport alone.
** CVE removed: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=2023-49298
** Description changed:
- OpenZFS 2.2 reportedly has a bug where block cloning
seth-arnold: yes, I do think we need to backport it all the way back.
And since it is kernel code, it sort of should go via normal SRU, and be
integrated into a kernel cycle and release over time. As actually
releasing zfs-linux into security pocket will not actually do much for
most users that
Oh, one other thing: the CVE is unlikely to be anything. No one knows
who posted it, and the scenario it describes is extremely vague and at
best, suggests the author didn't actually understand the issue.
--
You received this bug notification because you are a member of Kernel
Packages, which is
Hi all,
Patch for 0.8 (and others) available here:
https://zfsonlinux.topicbox.com/groups/zfs-
discuss/T12876116b8607cdb/lseek-glitch-dirty-dnode-patches-for-older-
openzfs-zfs-on-linux
If you didn't want to take all of 2.2.2 or 2.1.14, specific patches for
those series are:
Since this bug has been around since 2006, is there a possibility this
will be backported to the 0.8.3-1ubuntu12.15 version of ZFS? It's the
up-to-date version of ZFS installed on systems here with ubuntu 20.04.6.
OS: Ubuntu 20.04.6 LTS x86_64
Kernel: 5.4.0-167-generic
uname -a
Linux archive-box
@seth-arnold -- Thank you for those links. Those explain a lot of what
is currently happening, and the changes coming down.
This was comforting from robn:
"If you can't get an updated ZFS (2.2.2, 2.1.14, or a patch from your vendor)
then 'dmu_offset_next_sync=0' is the next best thing."
Anyone
xnox, rincebrain came to the conclusion that the conditions for this bug
have existed since 0.6.2:
https://gist.github.com/rincebrain/e23b4a39aba3fadc04db18574d30dc73 and
robn thinks the conditions for this bug was introduced in 2006:
@toekneefan -- Our tests of 2.2.1 from Noble Proposed showed that it was
actually "enabled" by default, instead of being disabled like they said
they did in it's release notes... So the rpool installs as "active", and
any other pools created with feature=default (or just omitted) are
created as
@toekneefan I know the workforce is always limited and I don't want to
blame anyone. After all, I'm not paying for support.
However, silent data corruption in a file system that is supposed to
first and foremost prevent silent data corruption is a serious defect,
and I understand that people are
@mafoelffen I'm sure the developers are hard at work with this and other
issues.
Ubuntu LTS, I believe, does not yet have coreutils v9, so it is unlikely
to be affected. This bug is actually extremely old (possibly going back
almost two decades), but recent changes, such as a change to
I wondered why my old bug report has not gotten any attention. Being a
duplicate of this bug didn't help, but at least someone from the
security team marked it as a duplicate of this bug.
BUT... On Bug Reports filed against zfs-linux, there are 55 bugs, with
not one single person assigned, that
This is my merge fo a Bug Report marked as a duplicate of this one:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044969
In the OpenZFS patch thread, they had said that feature@block_cloning,
because of the underlying bug, OpenZFS had said they turned that feature
off by default in
2.2.2 (version containing a fix for this) is now out
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.2
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-6.5 in Ubuntu.
https://bugs.launchpad.net/bugs/2044657
Title:
zfs
Forgot to mention you also need coreutils-9.0 or later, or some other
program that uses lseek SEEK_HOLE/SEEK_DATA as that is the culprit for
the bug. Essentially it errorneously reports holes in files that are
still dirty buffers. I had a local copy of "cp" from coreutils/sid
compiled for jammy.
Reproducible on Ubuntu 22.04 LTS w/ linux-hwe-6.2 (zfs-2.1.9) using the
NixOS test suite:
[zhammer::647] checking 1 files at iteration 0
[zhammer::647] zhammer_647_0 differed from zhammer_647_576!
[zhammer::647] Hexdump diff follows
--- zhammer_647_0.hex 2023-11-30 15:37:43.887596987 +
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux-hwe-6.2 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-6.5 in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux-hwe-6.5 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-6.5 in Ubuntu.
It appears upstream is prepping a 2.1.14 and 2.2.2 release that includes this
fix to both branches.
https://github.com/openzfs/zfs/pull/15601
https://github.com/openzfs/zfs/pull/15602
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
** Patch added: "Patch from OpenZFS master branch"
https://github.com/openzfs/zfs/commit/30d581121bb122c90959658e7b28b1672d342897.patch
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-6.5 in Ubuntu.
** Patch added: "Patch for OpenZFS 2.1"
https://github.com/openzfs/zfs/commit/e49b10f57c770a03217e6537252c90550aadb538.patch
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-6.5 in Ubuntu.
Apparently the bug was not in block cloning, it was just exacerbated by
it. The issue affects older versions of ZFS as well, including 2.1.x.
That is why the upstream OpenZFS project has backported the patch to
2.1.x (Chad linked the PR above). Thus, linux-hwe-6.2 is affected.
** Also affects:
I'm not sure why linux-hwe-6.2 is marked as affected. hwe-6.2 use 2.1.9
based zfs-linux and will not be upgraded to use 2.2.0 series.
** Package changed: linux-hwe-6.2 (Ubuntu) => linux-hwe-6.5 (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux-hwe-6.5 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
Apparently 2.2.1 did not fix the issue, there is an on-going PR
https://github.com/openzfs/zfs/pull/15571 that has the latest fix for
the data corruption. As a side note it also affects zfs 2.1 series
(block cloning made it more evident, but apparently possible to happen
on earlier zfs releases),
zfs-linux (2.2.1-0ubuntu1) noble; urgency=medium
* New upstream release.
Uploaded. But I don't want to close this bug report, because it is not
clear if that is everything yet or not.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
FreeBSD has released an official advisory for the issue today:
https://lists.freebsd.org/archives/freebsd-
stable/2023-November/001726.html
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
The attachment "0001-Fix-block-cloning-corruption-bug.patch" seems to be
a debdiff. The ubuntu-sponsors team has been subscribed to the bug
report so that they can review and hopefully sponsor the debdiff. If
the attachment isn't a patch, please remove the "patch" flag from the
attachment,
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: zfs-linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
Below is a potential fix/workaround for noble. This includes the two
upstream commits
https://github.com/openzfs/zfs/commit/03e9caaec006134b3db9d02ac40fe9369ee78b03
and
https://github.com/openzfs/zfs/commit/479dca51c66a731e637bd2d4f9bba01a05f9ac9f
to make block cloning optional and then disable it
There is also a CVE that seems to be caused by the same bug:
https://nvd.nist.gov/vuln/detail/CVE-2023-49298
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-49298
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
30 matches
Mail list logo
