On Fri, Jan 12, 2024 at 8:18 AM Jan Ingvoldstad <frett...@gmail.com> wrote: > > On Wed, Jan 10, 2024 at 10:48 PM Xiyue Deng <manp...@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.
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
