[UBUNTU 24.04] OS guest boot issues on 9p filesystem

[bugproxy]

[ Impact ]

Users of the 9p filesystem may encounter problems when guests try to access host files, which can lead to e.g. guest boot issues.

[ Test plan ]

Using the script kindly provided by the reporter, we can set up our test environment as such (this requires an s390x machine):

$ lxc profile create lp2091099
$ lxc profile edit lp2091099 << _EOF_
name: kvm-nodisk
description: ""
config:
  boot.autostart: "true"
  linux.kernel_modules: openvswitch,nbd,ip_tables,ip6_tables,kvm
  security.nesting: "true"
  security.privileged: "true"
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
  kvm:
    path: /dev/kvm
    type: unix-char
  mem:
    path: /dev/mem
    type: unix-char
  tun:
    path: /dev/net/tun
    type: unix-char
_EOF_
$ lxc launch ubuntu-daily:noble n-9ptest --profile default --profile lp2091099
$ lxc shell n-9ptest
# apt update
# apt install -y qemu-system-s390x debootstrap
# cat > t.sh << _EOF_
#!/bin/bash

# Cleanup target dir
[ -d ./target ] && rm -rf target
mkdir target

# Add configuration updates
mkdir -p ./target/etc/initramfs-tools/
echo 9p >> ./target/etc/initramfs-tools/modules
echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules

# Add the test script
cat > ./target/test_init << EOF
#!/bin/bash

echo "Test for unix domain sockets"

nc -Ul /socket &
sleep 1
echo "Sockets work" | nc -UN /socket || echo "Sockets fail"

echo o > /proc/sysrq-trigger
sleep 999
EOF
chmod 700 ./target/test_init

# Create an Ubuntu 23.10 around it
echo "Creating Ubuntu target OS"
debootstrap --variant=minbase\
            --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \
            --exclude=man,bash-completion \
            noble ./target > /dev/null || exit 1

# Run the test in 9p forwarded filesystem
echo "Running OS in qemu"
qemu-system-s390x \
  -m 8192 \
  -smp 4 \
  -nodefaults -nographic -no-reboot -no-user-config \
  -kernel ./target/boot/vmlinuz \
  -initrd ./target/boot/initrd.img \
  -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \
  -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \
  -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \
  -device virtio-serial-ccw -device sclpconsole,chardev=console \
  -chardev stdio,id=console,signal=off
_EOF_
# sh ./t.sh

On a problematic system, you should see something similar to the following output:

Creating Ubuntu target OS
Running OS in qemu
KASLR disabled: CPU has no PRNG
KASLR disabled: CPU has no PRNG
Test for unix domain sockets
qemu-system-s390x: 9p: broken or compromised client detected; attempt to open special file (i.e. neither regular file, nor directory)
nc: No such device or address
nc: /socket: No such file or directory
Sockets fail

[ Where problems could occur ]

This failure is caused by a regression introduced by a fix to a CVE. As such, the possibility of introducing a security regression needs to be considered. The CVE fix was about preventing guests to open files on the host when using 9p, but it ended up being too restrictive and impacting use cases when there needs to be an access.

The patch is not too complex and is specifically aimed at allowing open(2) with O_PATH, which is an operation that is as secure as possible without actually opening the file. According to the manpage:

 O_PATH (since Linux 2.6.39)
        Obtain a file descriptor that can be used for two purposes: to indicate a location in the filesystem tree and to perform operations that act purely at the file descriptor level. The file itself is not opened, and other file operations (e.g., read(2), write(2), fchmod(2), fchown(2), fgetxattr(2), ioctl(2), mmap(2)) fail with the error EBADF.

[ Original Description ]

== Reported by <email address hidden> - 2024-12-04 ==

---Problem Description---
[UBUNTU 24.04] OS guest boot issues on 9p filesystem

---uname output---
Linux winlnxnw 6.8.0-45-generic #45-Ubuntu SMP Fri Aug 30 11:09:37 UTC 2024 s390x s390x s390x GNU/Linux

Contact Information = <email address hidden>

Machine Type = 3931-7G4

---Steps to Reproduce---
 Run this script (fails with a qemu error message)

#!/bin/bash

# Cleanup target dir
[ -d ./target ] && rm -rf target
mkdir target

# Add configuration updates
mkdir -p ./target/etc/initramfs-tools/
echo 9p >> ./target/etc/initramfs-tools/modules
echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules

# Add the test script
cat > ./target/test_init << EOF
#!/bin/bash

echo "Test for unix domain sockets"

nc -Ul /socket &
sleep 1
echo "Sockets work" | nc -UN /socket || echo "Sockets fail"

echo o > /proc/sysrq-trigger
sleep 999
EOF
chmod 700 ./target/test_init

# Create an Ubuntu 23.10 around it
echo "Creating Ubuntu target OS"
debootstrap --variant=minbase\
            --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \
            --exclude=man,bash-completion \
            noble ./target > /dev/null || exit 1

# Run the test in 9p forwarded filesystem
echo "Running OS in qemu"
qemu-system-s390x \
  -m 8192 \
  -smp 4 \
  -nodefaults -nographic -no-reboot -no-user-config \
  -kernel ./target/boot/vmlinuz \
  -initrd ./target/boot/initrd.img \
  -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \
  -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \
  -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \
  -device virtio-serial-ccw -device sclpconsole,chardev=console \
  -chardev stdio,id=console,signal=off

---Debugger---
A debugger is not configured

Userspace tool obtained from project website: na

Userspace rpm: qemu-(current).deb

Userspace tool common name: qemu

The userspace tool has the following bit modes: both

*Additional Instructions for <email address hidden>:
-Post a private note with access information to the machine that the bug is occuring on.
-Attach ltrace and strace of userspace application.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2024-12-05 07:22 EDT-------
This bug was already detected in Jammy and was fixed in Ubuntu 22.04 (package qemu - 1:6.2+dfsg-2ubuntu6.21)
==> see bugzilla / LP item 'Bug 206380 - LP2065579 : [UBUNTU 22.04] OS guest boot issues on 9p filesystem'

Now, the problem seems to be back with Noble.

------- Comment From <email address hidden> 2024-12-05 07:25 EDT-------
From the original Jammy bug:

This Bug is the result of the fix to:
CVE-2023-2861: Prohibit opening any special file directly on host

I also opened a Bug in the qemu bugtracker
https://gitlab.com/qemu-project/qemu/-/issues/2337

The containers fail because syslog cannot open its unix domain socket on the filesystem.
We tracked the change that provokes this error to a CVE change in qemu that forbids opening of special files to
prevent exposing data from the host. Special files should be handled by the guest os.
Unix domain socket files are also special files, and they are handled by the guest OS in their entirety, and the 9p server in qemu assigns them individual inodes so they are safe to open. But they must be opened so their fd can be passed to the appropriate connect() or bind() function so the OS can use them.
Socket files don't have a traditional read or write functionality, they are mere representatives for a local address.
There is no convention for where domain socket files should go, so there is no easy fix by just creating a tmpfs somewhere.
We also see other workloads and services failing for not being able to open their local socket files.

The analysis of CVE-2023-2861 in detail reveals
- opening of device files through the 9p server directly grants access to read/write functions of those device files. Also device files can be created in-place anywhere.
- opening of FIFOs is somewhat unsafe as long as there are possible collisions that could expose host data using read/write.
- opening of sockets is safe because the 9p server protects the revealed inode and provides no way to connect the file to a socket.

The qemu team has made a change, but that only made things different, not better.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2024-12-09 10:26 EDT-------
A fix was posted by the maintainer on qemu-devel

diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index 51c94b0116..95ee4da9bd 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -177,20 +177,27 @@ again:
return -1;
}
- if (close_if_special_file(fd) < 0) {
- return -1;
- }
-
- serrno = errno;
- /* O_NONBLOCK was only needed to open the file. Let's drop it. We don't
- * do that with O_PATH since fcntl(F_SETFL) isn't supported, and openat()
- * ignored it anyway.
- */
+ /* Only if O_PATH is not set ... */
if (!(flags & O_PATH_9P_UTIL)) {
+ /*
+ * Prevent I/O on special files (device files, etc.) on host side,
+ * however it is safe and required to allow opening them with O_PATH,
+ * as this is limited to (required) path based operations only.
+ */
+ if (close_if_special_file(fd) < 0) {
+ return -1;
+ }
+
+ serrno = errno;
+ /*
+ * O_NONBLOCK was only needed to open the file. Let's drop it. We don't
+ * do that with O_PATH since fcntl(F_SETFL) isn't supported, and
+ * openat() ignored it anyway.
+ */
ret = fcntl(fd, F_SETFL, flags);
assert(!ret);
+ errno = serrno;
}
- errno = serrno;
return fd;
}
--
2.39.5

this fixes the issue for me.

[Sergio Durigan Junior (sergiodj)]

Thank you. I'm working on backporting the fix now. I'll run tests and hopefully get the SRU going by the end of the day.

[Sergio Durigan Junior (sergiodj)]

Upstream fixed it with https://gitlab.com/qemu-project/qemu/-/commit/d06a9d843fb65351e0e4dc42ba0c404f01ea92b3.

I'm now building a package containing the backported fix in my PPA (https://launchpad.net/~sergiodj/+archive/ubuntu/qemu). I should be able to put an MP up for review tomorrow.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2024-12-17 11:52 EDT-------
@sergiodj

did the MP go through ?

[Sergio Durigan Junior (sergiodj)]

Hi,

Not yet, unfortunately. The SRU team is not really reviewing/accepting new uploads this week due to the end-of-year break, so we're pretty much stuck until next year (there are actually a few other bugs that need to be fixed in QEMU and I will do one single upload for everything).

I will let you know when the situation changes. Thanks for the patience.

[Sergio Durigan Junior (sergiodj)]

I uploaded the fix to Plucky, Oracular and Noble, after confirming that it works for each one of those releases.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2025-01-08 03:44 EDT-------
May I know when it will be available with Noble?

[Sergio Durigan Junior (sergiodj)]

On Wednesday, January 08 2025, bugproxy wrote:

> ------- Comment From <email address hidden> 2025-01-08 03:44 EDT-------
> May I know when it will be available with Noble?

It needs to be processed by the SRU team first. Once that's done, we
will need to verify the fix, and then the package should reach the
release pocket in about 7 days after that.

--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2025-01-08 23:40 EDT-------
@sergiodj - Thanks for the update.

May we know by when would the fix be released ?
We have a release pending due to this fix.

Also, is there any way for us to verify the new qemu package ?
I do not see it marked here - https://launchpad.net/~sergiodj/+archive/ubuntu/qemu?field.series_filter=

[Andreas Hasenack (ahasenack)]

I'm on my SRU shift today and am looking at this update right now.

[Andreas Hasenack (ahasenack)]

Hello bugproxy, or anyone else affected,

Accepted qemu into oracular-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:9.0.2+ds-4ubuntu5.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-oracular to verification-done-oracular. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-oracular. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Andreas Hasenack (ahasenack)]

Hello bugproxy, or anyone else affected,

Accepted qemu into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Sergio Durigan Junior (sergiodj)]

Hello niranjuv,

As you can see, the SRU processed the uploads. You can find instructions on how to perform the verification in the emails above.

Thanks.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted qemu (1:8.2.2+ds-0ubuntu1.5) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

cloud-utils/unknown (i386)
debos/unknown (amd64)
freedom-maker/unknown (amd64)
glib2.0/2.80.0-6ubuntu3.2 (ppc64el)
gobject-introspection/1.80.1-1 (amd64)
libvirt/10.0.0-2ubuntu8.5 (amd64, ppc64el)
multipath-tools/unknown (amd64)
sbuild/0.85.10ubuntu0.1 (ppc64el)
sbuild/unknown (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#qemu

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2025-01-12 23:56 EDT-------
Hi sergiodj,

Is the SRU stage passed ?

Do we have any update on the release date ?

[Andreas Hasenack (ahasenack)]

I retried the failing autopkgtests[1], since all but one were problems in the autopkgtest infrastructure (the tell is when the version of the package is flagged as "unknown").

1. https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#qemu

[Sergio Durigan Junior (sergiodj)]

Performing the verification on Noble.

First, making sure that the bug manifests when using the current version from the archive.

# apt policy qemu-system-s390x
qemu-system-s390x:
  Installed: 1:8.2.2+ds-0ubuntu1.4
  Candidate: 1:8.2.2+ds-0ubuntu1.4
  Version table:
 *** 1:8.2.2+ds-0ubuntu1.4 500
        500 http://ports.ubuntu.com/ubuntu-ports noble-updates/main s390x Packages
        500 http://ports.ubuntu.com/ubuntu-ports noble-security/main s390x Packages
        100 /var/lib/dpkg/status
     1:8.2.2+ds-0ubuntu1 500
        500 http://ports.ubuntu.com/ubuntu-ports noble/main s390x Packages

# sh ./t.sh
Creating Ubuntu target OS
Running OS in qemu
KASLR disabled: CPU has no PRNG
KASLR disabled: CPU has no PRNG
Test for unix domain sockets
qemu-system-s390x: 9p: broken or compromised client detected; attempt to open special file (i.e. neither regular file, nor directory)
nc: No such device or address
nc: /socket: No such file or directory
Sockets fail

Now, upgrading the package to the version in -proposed and verifying that it fixes the problem.

# apt policy qemu-system-s390x
qemu-system-s390x:
  Installed: 1:8.2.2+ds-0ubuntu1.5
  Candidate: 1:8.2.2+ds-0ubuntu1.5
  Version table:
 *** 1:8.2.2+ds-0ubuntu1.5 100
        100 http://ports.ubuntu.com/ubuntu-ports noble-proposed/main s390x Packages
        100 /var/lib/dpkg/status
     1:8.2.2+ds-0ubuntu1.4 500
        500 http://ports.ubuntu.com/ubuntu-ports noble-updates/main s390x Packages
        500 http://ports.ubuntu.com/ubuntu-ports noble-security/main s390x Packages
     1:8.2.2+ds-0ubuntu1 500
        500 http://ports.ubuntu.com/ubuntu-ports noble/main s390x Packages

# sh ./t.sh
Creating Ubuntu target OS
Running OS in qemu
KASLR disabled: CPU has no PRNG
KASLR disabled: CPU has no PRNG
Test for unix domain sockets
Sockets work

This concludes the verification on Noble.

[Sergio Durigan Junior (sergiodj)]

Performing the verification on Oracular.

First, making sure that the bug manifests when using the current version from the archive.

# apt policy qemu-system-s390x
# apt policy qemu-system-s390x
qemu-system-s390x:
  Installed: 1:9.0.2+ds-4ubuntu5.1
  Candidate: 1:9.0.2+ds-4ubuntu5.1
  Version table:
 *** 1:9.0.2+ds-4ubuntu5.1 500
        500 http://ports.ubuntu.com/ubuntu-ports oracular-updates/main s390x Packages
        500 http://ports.ubuntu.com/ubuntu-ports oracular-security/main s390x Packages
        100 /var/lib/dpkg/status
     1:9.0.2+ds-4ubuntu5 500
        500 http://ports.ubuntu.com/ubuntu-ports oracular/main s390x Packages

# sh ./t.sh
# sh ./t.sh
Creating Ubuntu target OS
Running OS in qemu
KASLR disabled: CPU has no PRNG
KASLR disabled: CPU has no PRNG
Test for unix domain sockets
qemu-system-s390x: 9p: broken or compromised client detected; attempt to open special file (i.e. neither regular file, nor directory)
nc: No such device or address
nc: /socket: No such file or directory
Sockets fail

Now, upgrading the package to the version in -proposed and verifying that it fixes the problem.

# apt policy qemu-system-s390x
# apt policy qemu-system-s390x
qemu-system-s390x:
  Installed: 1:9.0.2+ds-4ubuntu5.2
  Candidate: 1:9.0.2+ds-4ubuntu5.2
  Version table:
 *** 1:9.0.2+ds-4ubuntu5.2 100
        100 http://ports.ubuntu.com/ubuntu-ports oracular-proposed/main s390x Packages
        100 /var/lib/dpkg/status
     1:9.0.2+ds-4ubuntu5.1 500
        500 http://ports.ubuntu.com/ubuntu-ports oracular-updates/main s390x Packages
        500 http://ports.ubuntu.com/ubuntu-ports oracular-security/main s390x Packages
     1:9.0.2+ds-4ubuntu5 500
        500 http://ports.ubuntu.com/ubuntu-ports oracular/main s390x Packages

# sh ./t.sh
# sh ./t.sh
Creating Ubuntu target OS
Running OS in qemu
KASLR disabled: CPU has no PRNG
KASLR disabled: CPU has no PRNG
Test for unix domain sockets
Sockets work

This concludes the verification on Oracular.

[Sergio Durigan Junior (sergiodj)]

Hello niranjuv,

I performed the verification for both uploads (I thought you wanted to do that, but I decided to do it myself in order to speed things up). We have to wait 7 days after the SRU team accepted the packages so that they can be properly released. On top of that, we are facing some problems with our test infrastructure which is slowing things down a bit.

I'll work on expediting the test results now, but we are still constrained by the 7-day aging period.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2025-01-15 00:58 EDT-------
Thanks for the update @sergiodj.

So, could we expect the release around Jan 25th 2025 ?

[Frank Heimes (fheimes)]

Hi @niranjuv,
we are working to get this solved and the fix published on several levels.

Since this is a bug that also needs to be fixed in Ubuntu releases that are already out and in service, we are required to follow the Ubuntu SRU "stable release update" process that is pretty strict (by intention).
It requires the completion of quite significant (and of course successful) testing - without this the updated package is not acceptable by our SRU team and cannot be rolled out and published.

The SRU process is in place to take as much care as possible on such SRU updates, since what we (all) want to avoid are regressions. And in case of Ubuntu (and especially Ubuntu LTS releases) that can quickly affect multi-millions of installations.
And that's also the reason why the fix needs to be rolled out from newest (current development) release to oldest affected release, just to avoid any regression in case of Ubuntu release upgrades.

The SRU process for packages is unfortunately queue based (in contrast to kernel SRUs, which happen in more or less fixed cycles - every 2 / 4 weeks).
And over the YE break packages in the queue pilled up a bit.
Canonical's Ubuntu distro teams are working on this backlog.
But since it's queue based, it's difficult to give an ETA.

The so called "aging period" is a fixed part of the SRU process and is in place to allow not only our testing to be completed, but also other people's testing in their particular environments.

With that let me point out two more things:

i)
An updated package with a fix included is already available now, but via the so called -proposed archive pocket.
Nevertheless, everyone who enabled or opted-in to use -proposed can install, test and use that package.
But until the testing is completed and the aging period is over, it will stay in -proposed, means it will not be visible for default installations (where -proposed is disabled).
At the end of the aging period - and in case no regressions were found - this exact same package will transition from the -proposed to the -updates (respectively -security) pocket, and will become available as regular update for everyone.

Since I'm unsure if our automated SRU messages/comments here in Launchpad (like https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2091099/comments/13) are detailed enough,
let me quickly list the steps on how to get the updated package installed from proposed:
sudo add-apt-repository -y "deb http://ports.ubuntu.com/ubuntu-ports/ $(lsb_release -sc)-proposed main universe"
sudo apt -y update # if not automatically done by the previous command
sudo apt -y -t=$(lsb_release -sc)-proposed install qemu-system # or maybe more fine grained 'qemu-system-s390x'

ii)
One may think that this SRU process is a bit lengthy and there must be a quicker way to get a fixed package more quickly into production environments.
And that is true, in such cases, Ubuntu users that have a subscription in place (called 'Ubuntu Pro'), are eligible to open a SalesForce (support) case at Canonical.
With that our service and support colleagues (rather than we, development) will pick this up.
And they have the option to bridge the gap/time that is caused by ...

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:9.0.2+ds-4ubuntu5.2

---------------
qemu (1:9.0.2+ds-4ubuntu5.2) oracular; urgency=medium

  * d/p/u/lp-2091099-fix-9p-regression-cve-2023-2861.patch: Fix
    regression regarding CVE-2023-2861 affecting 9p filesystems.
    (LP: #2091099)

 -- Sergio Durigan Junior <email address hidden> Tue, 07 Jan 2025 18:18:14 -0500

[Andreas Hasenack (ahasenack)]

The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:8.2.2+ds-0ubuntu1.5

---------------
qemu (1:8.2.2+ds-0ubuntu1.5) noble; urgency=medium

  * d/p/u/lp-2091099-fix-9p-regression-cve-2023-2861.patch: Fix
    regression regarding CVE-2023-2861 affecting 9p filesystems.
    (LP: #2091099)

 -- Sergio Durigan Junior <email address hidden> Wed, 11 Dec 2024 22:06:49 -0500

[Andreas Hasenack (ahasenack)]

The plucky task is still open, but the upload fixing it is in proposed, so that's good enough.

There is a oracular/i386 autopkgtest stuck in "running", but the history shows it never passed, so that's ok too.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2025-01-24 07:07 EDT-------
Thanks for the update @sergiodj

Tried with downloading the 1:8.2.2+ds-0ubuntu1.5 package version for qemu-system-common, qemu-system-data and qemu-system-s390x using `apt-get download` and installed the same using `dpkg -i`.

Unfortunately we are seeing the same issue.

Are we missing anything ?

[Sergio Durigan Junior (sergiodj)]

Hello,

I don't know how you downloaded the packages you're mentioning, but the best way to test this update is by following the instructions given by the SRU team on comment #13. Namely:

- You need to enable the -proposed repository on your system (instructions at https://wiki.ubuntu.com/Testing/EnableProposed).

- You need to upgrade the QEMU package from this repository. For example, if you're on Noble:

apt -t noble-proposed install qemu-system-s390x

This should be enough to tell apt to upgrade all QEMU packages that are needed.

- Then you can perform your tests.

If that doesn't work, could you please let me know which steps you're taking to verify the fix, please? Are they the same steps described in the "Test plan" section (from this bug's description)?

Thanks.

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:9.0.2+ds-4ubuntu9

---------------
qemu (1:9.0.2+ds-4ubuntu9) plucky; urgency=medium

  * d/p/u/lp-2091099-fix-9p-regression-cve-2023-2861.patch: Fix
    regression regarding CVE-2023-2861 affecting 9p filesystems.
    (LP: #2091099)

 -- Sergio Durigan Junior <email address hidden> Tue, 07 Jan 2025 14:56:38 -0500

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2025-01-27 07:15 EDT-------
Hi @sergiodj,

The package needs to be manually downloaded and installed in my setup which does not connect to Ubuntu ports.

I tried to update the /etc/apt/sources.list.d/ubuntu.sources file with noble-proposed and tried the below command -

niranjuv@ubuntu24:/tmp$ sudo apt -t noble-proposed download qemu-system-s390x
E: The value 'noble-proposed' is invalid for APT::Default-Release as such a release is not available in the sources.

Could we have a path to download the package and verify ?

[Frank Heimes (fheimes)]

Hi 'niranjuv',
please notice that these updated packages are for 24.04 (code-name 'noble'), you cannot test them properly on a different Ubuntu release.
Please double check with "lsb_release -a".

If you need to install the packages on an isolated system, it's of course a bit more work.
In case you have a system (s390x, 24.04) that has connectivity, you may download the packages with the help of "apt-get download ...", transfer them install them from local disk for example with "apt install *.deb".

Or fetch them package by package from here:
https://launchpad.net/ubuntu/+source/qemu
https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1.5
(s390x:) https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1.5/+build/29976972
then transfer and install ...

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2025-01-27 08:45 EDT-------
Sorry for the confusion... My bad I had some issue on the system..

I could get the packages downloaded from noble-proposed branch -

niranjuv@ubuntu24:/tmp$ sudo apt -t noble-proposed download qemu-system-s390x
[sudo] password for niranjan:
Get:1 http://ports.ubuntu.com/ubuntu-ports noble-updates/main s390x qemu-system-s390x all 1:8.2.2+ds-0ubuntu1.5 [1,790 kB]
Fetched 1,790 kB in 0s (8,129 kB/s)

Similarly tried to get qemu-system-data and qemu-system-common from noble-proposed branch and see that the issue is not resolved.

Could be that the fix is part of multiple packages and I am not having all of them at my place.

Please let me know.

[Sergio Durigan Junior (sergiodj)]

It is not clear to me why you did not use "apt install" instead of "apt download". In order to further diagnose the issue, we need more information.

1) How are you actually installing the packages?

2) What tests are you performing? Are you running the test provided in the "Test plan" section of the bug?

3) What exactly are you seeing on your system when you run the tests?

It would be very helpful if you could provide a step-by-step reproducer of the problem you're experiencing. As you can check on comment #18, I did the verification myself and confirmed that the package fixes the problem as outlined in the "Test plan" section of the bug.

Thank you.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2025-01-28 02:30 EDT-------
The setup where the issue is reproduced does not have external connectivity. So, I would not be able to execute "apt install" over there.

- The above packages are installed using dpkg -I <pkg_name>
- After installing packages with the above step, I am trying to run the script mentioned in Comment #1 and see the issue not being fixed.

[Frank Heimes (fheimes)]

Hello niranjuv

'apt' also allows to install local packages, if you point it to a local package using a local path, like:
apt install ./*.deb
it has the advantage that it resolves the dependency chain nicely
but, yes, 'dpkg -I' is a valid alternative

I'm a bit confused that the verification worked fine here on noble:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2091099/comments/18

(just a wild guess) Since KVM has also kernel parts, this might be due to a different (maybe outdated) kernel?
Can you check if you are on the latest kernel level (and having it active: uname -a)?