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