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 <[email protected]> > 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 <[email protected]> > 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/[email protected]/ /Christian
