Bookworm and ZFS (zfs-dkms 2.1.11) data corruption bug

[Jan Ingvoldstad]

Hi,

It seems that Bookworm's zfs-dkms package (from contrib) has the data corruption bug that was fixed with OpenZFS 2.1.14 (and 2.2.2) on 2023-11-30.

https://github.com/openzfs/zfs/releases/tag/zfs-2.1.14

However, I see no relevant bug report in the bug tracker - have my searching skills failed?

--

Jan

[Gareth Evans]

> On 9 Jan 2024, at 06:41, Jan Ingvoldstad <fret...@gmail.com> wrote:
> 

This prompted me to look for updates.

2.2.2-3 is available in bookworm-backports.

Is this, or a later version, likely to be made available in bookworm-updates?

Does anyone have experience with the backports version?

Thanks
Gareth

[Xiyue Deng]

You can check the developer page of zfs-linux[1] on which the "action
needed" section has information about security issues (along with
version info as Gareth posted). The one you mentioned was being tracked
in [2] and the corresponding Debian bug is [3]. My guess is that as
zfs-linux is not in "main" but "contrib", and the issue is marked
"no-dsa" (see [4]), there may be no urgency to provide a stable update.
But you may send a follow up in the tracking bug and ask for
clarification from the maintainers on whether an (old)stable-update is
desired.

[1] https://tracker.debian.org/pkg/zfs-linux
[2] https://security-tracker.debian.org/tracker/CVE-2023-49298
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056752
[4] https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory

--
Xiyue Deng

[Махно]

It is recommended by Debian ZFS on Linux Team to install ZFS related
packages from Backports archive. Upstream stable patches will be
tracked and compatibility is always maintained.

[Jan Ingvoldstad]

On Wed, Jan 10, 2024 at 10:48 PM Xiyue Deng <man...@gmail.com> wrote:

You can check the developer page of zfs-linux[1] on which the "action
needed" section has information about security issues (along with
version info as Gareth posted).  The one you mentioned was being tracked
in [2] and the corresponding Debian bug is [3].  My guess is that as
zfs-linux is not in "main" but "contrib", and the issue is marked
"no-dsa" (see [4]), there may be no urgency to provide a stable update.
But you may send a follow up in the tracking bug and ask for
clarification from the maintainers on whether an (old)stable-update is
desired.

 

Thanks, so it *was* my searching skills that failed me:

"The fix will land in bookworm-backports and bullseye-backports-sloppy
shortly after 2.1.14-1 migrates to testing, which will take about 2
days hopefully. Fixes to 2.0.3-9+deb11u1 (bullseye) and 2.1.11-1
(bookworm) are planned but will likely take more time."

I think the bug is mislabeled as "security" and "important", as this is primarily a severe data corruption bug, but with *possible* security implications.

It is far more concerning that one cannot trust that cp actually copies a file, and this is a blocker for installing the ZFS packages in Debian.

--

Jan

[Махно]

>I have not seen this recommendation, do you have a link?

It is from Debian wiki

https://wiki.debian.org/ZFS

[Gareth Evans]

On Fri 12/01/2024 at 06:49, Jan Ingvoldstad <fret...@gmail.com> wrote:
> ...

> It is far more concerning that one cannot trust that cp actually copies a file, and this is a blocker for installing the ZFS packages in Debian.

The update in bookworm-backports to 2.2.2-3 allegedly fixes this issue.

I have installed it and at least rebooted :)

I have had ZFS on root since Buster, and have upgraded to each new stable release since then.

I had wondered recently if the Debian wiki's recommendation [1] of installing from "stable-backports", and the statement that

"Upstream stable patches will be tracked and compatibility is always maintained"

was to suggest use of the actual "stable-backports" repo, and that the compatibility guarantee meant that they cater for any potential ZFS issues arising for non-upgraded systems after new release time. On closer inspection, the line the wiki provides to add this to sources.list actually adds the codename-backports repo (currently "bookworm-backports"). "stable-backports" also appears to be an alias that apt understands as referring to {codename}-backports for whatever current stable is, and use of the actual "stable-backports" repo is not recommended or implied.

Is the Debian wiki advice re installing ZFS from backports applicable in all circumstances? What would be the suggested approach for installing with ZFS on root or re-pointing apt at backports for ZFS immediately after [upgrading to] a new stable release? Do backports even exist at that point? If so, after a release upgrade, can you install the same version of eg. zfs-dkms from backports as a sort of special case for the purposes of changing the repo? Or do you just have to watch and wait for new ZFS backports?

OpenZFS instructions [2] for root on ZFS suggest using bookworm not bookworm-backports, so I wondered if an initial lack of backports might be the reason.

Thanks,
Gareth

[1] https://wiki.debian.org/ZFS#Status
[2] https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Bookworm%20Root%20on%20ZFS.html#step-1-prepare-the-install-environment

[Gareth Evans]

On Sat 13/01/2024 at 02:32, Gareth Evans <dono...@fastmail.fm> wrote:
> use of the actual "stable-backports" repo is not
> recommended or implied.

"implied" might be debatable given that was indeed my first thought, but not intended to be implied, it seems. Certainly not necessary.

[Jeffrey Walton]

Using cp with sparse files has a long history of problems. Recently
this showed up: bug#61386: [PATCH] cp,mv,install: Disable sparse copy
on macOS, <https://lists.nongnu.org/archive/html/bug-coreutils/2023-02/msg00010.html>.
I seem to recall the problem was a little bigger than just macOS. It
affected other OSes, too. While it was propagated through coreutils, I
believe the underlying problem was Gnulib.

The ZFS issue looks to be similar, if I am parsing things correctly:
GH #11900: SEEK_DATA fails randomly,
<https://github.com/openzfs/zfs/issues/11900>.

Jeff