Re: [PULL 00/23] 9p queue 2026-06-29

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Wednesday, 1 July 2026 12:15:23 CEST Michael Tokarev wrote:
[...]
> Thank you for this work!

Hi Michael,

> FWIW, I've applied this to 11.0.x and 10.0.x.  For the latter, I also
> picked up the following two commits which are simple refactoring:
> 
> commit c84ebaa6b2cf9a27fc051b4692a42350adf6358e
> Author: Greg Kurz <groug@kaod.org>
> Date:   Wed Mar 12 16:29:28 2025 +0100
> 
>      9pfs: Don't use file descriptors in core code

That's actually f2bb367d2b265c6c0ead1e0d4a8f7c43310b3107

> commit 29070a13e7c131448ff35c90c70ff42e2989d420
> Author: Greg Kurz <groug@kaod.org>
> Date:   Wed Mar 12 16:29:27 2025 +0100
> 
>      9pfs: local : Introduce local_fid_fd() helper

And that's 4f82ce8cd94f2601fb2b2e4cfe0cf5b44131817e

Both are safe to be picked and required for the patches in this PR.

> What do you think, for older 7.2.x series, which was an LTS but now
> security-only support, which of the above should be picked up?
> I mean, which are the most important ones here?

Good question. It depends on what the exact policy on the reduced support
level means (for 7.2.x). I mean these are essentially all security related
patches, but with different impact:

- All issues in this PR require full root control over guest. They are not 
  possible exploits by regular guest users (so low to medium severity).

- Patch 8 prevents a potential DoS combined with unlimited host memory 
  allocation / exhaustion.

- Patch 9 also prevents a potential unlimited host memory allocation / 
  exhaustion, however that's a bit tricky to pick alone, as it introduces a 
  hard coded limit on the max. amount of open xattrs to client, a limit which 
  did not exist before at all. The limit is chosen high enough to 
  theoretically not cause issues, but you'll never know what happens in 
  guest's user space, therefore patch 10 introduced a configurable option for 
  this limit, which OTOH is odd to be back-ported to such old stable branches.

- Patches 21 .. 23 merely fix a rather theoretical issue. I have not 
  identified a way for a exploit on this issue. So probably can be omitted.

- Most of the other patches are test cases for guarding these fixed issues. No 
  idea if you usually pick tests up or not. They are useful though to verify 
  whether they fix the issues as intended. Note though that they are 
  registered as "slow" tests, which do not run by default, e.g.:

  cd build
  tests/qtest/qos-test -m slow

Also note that Pierrick reported that some of the tests introduced by this PR
failed at their end. I couldn't reproduce so far, it might be a false
positive, minor issue with the test environment, in worst case I still have to
fix something on the core patches. So keep an eye on that, please:

https://lore.kernel.org/qemu-devel/53159abf-ae84-465a-ac70-8ad71fa6c045@oss.qualcomm.com/

/Christian