The individual FID types (P9_FID_NONE, P9_FID_FILE, P9_FID_DIR, P9_FID_XATTR)
share union V9fsFidOpenState with FID-type specific fields. Accessing any of
the union fields must comply with the FID-type to avoid undefined behaviour
or information disclosure.

This series fixes invalid access of this union type at several locations.

* Patch 1 and Patch 2 are the core fixes checking the FID type on protocol
  level (9p.c) before allowing access to a FID-type specific union field.

* Patch 3 adds another safety layer by returning -1 from local_fid_fd() if
  the FID type would not have a valid file descriptor.

Christian Schoenebeck (3):
  hw/9pfs: fix invalid union access by v9fs_co_fsync()
  hw/9pfs: fix invalid union access by v9fs_co_fstat()
  hw/9pfs/local: harden local_fid_fd() on FID types

 hw/9pfs/9p-local.c |  5 ++++-
 hw/9pfs/9p.c       | 17 +++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletion(-)

-- 
2.47.3

On Tuesday, 16 June 2026 17:00:11 CEST Christian Schoenebeck wrote:
> The individual FID types (P9_FID_NONE, P9_FID_FILE, P9_FID_DIR,
> P9_FID_XATTR) share union V9fsFidOpenState with FID-type specific fields.
> Accessing any of the union fields must comply with the FID-type to avoid
> undefined behaviour or information disclosure.
> 
> This series fixes invalid access of this union type at several locations.
> 
> * Patch 1 and Patch 2 are the core fixes checking the FID type on protocol
>   level (9p.c) before allowing access to a FID-type specific union field.
> 
> * Patch 3 adds another safety layer by returning -1 from local_fid_fd() if
>   the FID type would not have a valid file descriptor.
> 
> Christian Schoenebeck (3):
>   hw/9pfs: fix invalid union access by v9fs_co_fsync()
>   hw/9pfs: fix invalid union access by v9fs_co_fstat()
>   hw/9pfs/local: harden local_fid_fd() on FID types
> 
>  hw/9pfs/9p-local.c |  5 ++++-
>  hw/9pfs/9p.c       | 17 +++++++++++++++++
>  2 files changed, 21 insertions(+), 1 deletion(-)

Queued on 9p.next:
https://github.com/cschoenebeck/qemu/commits/9p.next

Thanks!

/Christian

On 16.06.2026 18:00, Christian Schoenebeck wrote:
> The individual FID types (P9_FID_NONE, P9_FID_FILE, P9_FID_DIR, P9_FID_XATTR)
> share union V9fsFidOpenState with FID-type specific fields. Accessing any of
> the union fields must comply with the FID-type to avoid undefined behaviour
> or information disclosure.
..

Hi!

Next batch of qemu stable series is scheduled for Jun-25 (patch freeze at
Jun-23).  It would be great if this and other 9pfs fixes landed in the
master branch before the freeze.  As far as I can see, we've several
issues in there.

Thanks,

/mjt

On Wednesday, 17 June 2026 09:27:31 CEST Michael Tokarev wrote:
> On 16.06.2026 18:00, Christian Schoenebeck wrote:
> > The individual FID types (P9_FID_NONE, P9_FID_FILE, P9_FID_DIR,
> > P9_FID_XATTR) share union V9fsFidOpenState with FID-type specific fields.
> > Accessing any of the union fields must comply with the FID-type to avoid
> > undefined behaviour or information disclosure.
> 
> ..
> 
> Hi!
> 
> Next batch of qemu stable series is scheduled for Jun-25 (patch freeze at
> Jun-23).  It would be great if this and other 9pfs fixes landed in the
> master branch before the freeze.  As far as I can see, we've several
> issues in there.

Oh, that's quite close! What would be the next window?

This fix is already queued on my end:
https://lore.kernel.org/qemu-devel/cover.1780072238.git.qemu_oss@crudebyte.com/
https://github.com/cschoenebeck/qemu/commits/9p.next

And these fixes are yet to be queued:
https://lore.kernel.org/qemu-devel/cover.1781287774.git.qemu_oss@crudebyte.com/
https://lore.kernel.org/qemu-devel/cover.1781361555.git.qemu_oss@crudebyte.com/

And of course this series here:
https://lore.kernel.org/qemu-devel/cover.1781621428.git.qemu_oss@crudebyte.com/

At least I currently don't have further reports to work on. So all bugfix
patches are posted.

/Christian

On 17.06.2026 11:10, Christian Schoenebeck wrote:
...
>> Next batch of qemu stable series is scheduled for Jun-25 (patch freeze at
>> Jun-23).  It would be great if this and other 9pfs fixes landed in the
>> master branch before the freeze.  As far as I can see, we've several
>> issues in there.
> 
> Oh, that's quite close! What would be the next window?

I'm trying to make stable releases every month, but it rarely happens
this way :)  Previous delay between releases was more than 2 months.

> This fix is already queued on my end:
> https://lore.kernel.org/qemu-devel/cover.1780072238.git.qemu_oss@crudebyte.com/
> https://github.com/cschoenebeck/qemu/commits/9p.next
> 
> And these fixes are yet to be queued:
> https://lore.kernel.org/qemu-devel/cover.1781287774.git.qemu_oss@crudebyte.com/
> https://lore.kernel.org/qemu-devel/cover.1781361555.git.qemu_oss@crudebyte.com/
> 
> And of course this series here:
> https://lore.kernel.org/qemu-devel/cover.1781621428.git.qemu_oss@crudebyte.com/
> 
> At least I currently don't have further reports to work on. So all bugfix
> patches are posted.

Yeah, that's excellent.  Thank you for this stuff!
The next step is for all this to land in the master branch in the main
qemu repository - where I can pick it up for the stable branches :)

Thanks,

/mjt

On Wednesday, 17 June 2026 11:35:04 CEST Michael Tokarev wrote:
> On 17.06.2026 11:10, Christian Schoenebeck wrote:
[...]
> > At least I currently don't have further reports to work on. So all bugfix
> > patches are posted.
> 
> Yeah, that's excellent.  Thank you for this stuff!
> The next step is for all this to land in the master branch in the main
> qemu repository - where I can pick it up for the stable branches :)

I know, I just wanted to point out that I am usually not inclined to send out 
a PR with patches that only have been posted few days before, especially as 
they are going to pushed through several stables branches. You know, 
regressions, etc. ;-)

What about delaying the stable release for a week? Does that sound like a 
viable compromise?

/Christian

On 17.06.2026 12:59, Christian Schoenebeck wrote:
...
> I know, I just wanted to point out that I am usually not inclined to send out
> a PR with patches that only have been posted few days before, especially as
> they are going to pushed through several stables branches. You know,
> regressions, etc. ;-)

Ah, it's the opposite concern, - to introduce a regression, not to miss
the fix in time.  It's definitely a valid concern.

> What about delaying the stable release for a week? Does that sound like a
> viable compromise?

Let's make it into the next stable releases instead.  You can include
the set which is already published in your tree, and for the rest, let's
wait for the next round.  I don't plan to delay next stable releases.

Thanks,

/mjt

On Wednesday, 17 June 2026 12:43:09 CEST Michael Tokarev wrote:
> On 17.06.2026 12:59, Christian Schoenebeck wrote:
[...]
> > What about delaying the stable release for a week? Does that sound like a
> > viable compromise?
> 
> Let's make it into the next stable releases instead.  You can include
> the set which is already published in your tree, and for the rest, let's
> wait for the next round.  I don't plan to delay next stable releases.

Agreed.

The already queued 3 patches will certainly make it to master in-time for the 
stable release next week, but all other patches will miss that release window.

Thanks!

/Christian