On 03.07.2026 16:25, Peter Maydell wrote:
The local_fid_fd() function can fail (returning -1 if dirfd() fails);
check for this explicitly rather than relying on something later on
failing because it was passed a -1 file descriptor.
This was flagged up by Coverity: CID 1660923, 1660924, 1660925
Signed-off-by: Peter Maydell <[email protected]>
---
hw/9pfs/9p-local.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index ee592b62f8..8f27c562b5 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -788,6 +788,9 @@ static int local_fstat(FsContext *fs_ctx, int fid_type,
{
int err, fd = local_fid_fd(fid_type, fs);
+ if (fd < 0) {
+ return fd;
+ }
err = fstat(fd, stbuf);
I think this is a wrong approach - if we're going to report error due to
a failed (local_)fstat call, we'll use errno which is not set in this
codepath.
Instead we should check fd earlier.
In this particular context, we don't check possible error return from
dirfd() - which should not return error in our case, as we know we have
valid opendir() handle (unless we really messed up our memory layout,
but in this case we've much bigger problem).
Mayve
assert(dirft() >= 0)
in local_fid_fd() will be better.
In general, seeing code like the suggested in this patch, prompts me
thinking that fd can normally be negative in this context, - and handle
this situation in other cases too. But it really can't, and if it is,
it's an abnormal situation.
Thanks,
/mjt
