From: Forest <forestix@nom.one>
To: David Howells <dhowells@redhat.com>,
Steve French <sfrench@samba.org>,
Shyam Prasad N <nspmangalore@gmail.com>,
Rohith Surabattula <rohiths.msft@gmail.com>,
Jeff Layton <jlayton@kernel.org>
Cc: linux-cifs@vger.kernel.org, netfs@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
stable@vger.kernel.org, regressions@lists.linux.dev
Subject: [REGRESSION] cifs: triggers bad flatpak & ostree signatures, corrupts ffmpeg & mkvmerge outputs
Date: Sat, 24 Aug 2024 18:50:40 -0700 [thread overview]
Message-ID: <pv2lcjhveti4sfua95o0u6r4i73r39srra@sonic.net> (raw)
#regzbot introduced: 3ee1a1fc3981
Dear maintainers,
I think I have found a cifs regression in the 6.10 kernel series, which leads
certain programs to write corrupt data.
After upgrading from kernel 6.9.12 to 6.10.6, flatpak and ostree are now
writing bad gpg signatures when exporting signed packages or signing their
repository metadata/summary files, whenever the repository is on a cifs mount.
Instead of writing the signature data, null bytes are written in its place.
Furthermore, ffmpeg and mkvmerge are now intermittently writing corrupt files
to cifs mounts.
No error is reported by the applications or the kernel when it happens.
In the case of flatpak, the problem isn't revealed until something tries to use
the repository and finds signatures full of null bytes. (Of course, this means
the affected repositories have been rendered useless.) In the case of ffmpeg
and mkvmerge, the problem isn't revealed until someone plays the video file and
reaches a corrupt section.
A kernel bisect reveals this:
3ee1a1fc39819906f04d6c62c180e760cd3a689d is the first bad commit
commit 3ee1a1fc39819906f04d6c62c180e760cd3a689d
Author: David Howells <dhowells@redhat.com>
Date: Fri Oct 6 18:29:59 2023 +0100
cifs: Cut over to using netfslib
I was unable to determine whether 6.11.0-rc4 fixes it, due to another cifs bug
in that version (which I hope to report soon).
An strace of flatpak (which uses libostree) shows it generating correct
signatures internally, but behaving differently on cifs vs. ext4 when working
with memory-mapped temp files, in which the signatures are stored before being
written to their final outputs. Here's where I reported my initial findings to
those projects:
https://github.com/flatpak/flatpak/issues/5911
https://github.com/ostreedev/ostree/issues/3288
Debian Testing and Unstable kernels (6.10.4-1 and 6.10.6-1) are affected:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079394
The following reproducer script consistently triggers the problem for me. Run
it with two arguments: a path on a cifs mount where an ostree repo should be
created, and a GPG key ID with which to sign a commit.
#!/bin/sh
set -e
if [ "$#" -lt 2 ] || [ "$1" = "-h" ] ; then
echo "usage: $(basename "$0") <repo-dir> <gpg-key-id>"
exit 2
fi
repo=$1
keyid=$2
src="./foo"
echo "creating ostree repo at $repo"
ostree init --repo="$repo"
echo "creating source file tree at $src"
mkdir -p "$src"
echo hi > "$src"/hello
ostree commit --repo="$repo" --branch=foo --gpg-sign="$keyid" "$src"
if ostree show --repo="$repo" foo; then
echo ---
echo success!
else
echo ---
ostree show --repo="$repo" --print-detached-metadata-key=ostree.gpgsigs foo
echo failure!
echo look for null bytes in the above commit signature
fi
next reply other threads:[~2024-08-25 1:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-25 1:50 Forest [this message]
2024-08-27 18:38 ` Forest
2024-09-04 21:02 ` Forest
2024-09-04 22:01 ` David Howells
2024-09-05 7:32 ` Forest
2024-09-06 0:46 ` Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pv2lcjhveti4sfua95o0u6r4i73r39srra@sonic.net \
--to=forestix@nom.one \
--cc=dhowells@redhat.com \
--cc=jlayton@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netfs@lists.linux.dev \
--cc=nspmangalore@gmail.com \
--cc=regressions@lists.linux.dev \
--cc=rohiths.msft@gmail.com \
--cc=sfrench@samba.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox