netdev - Re: [PATCH] net: 9p: fix double req put in p9_fd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aJ68sV1kH2CQ8eYr@codewreck.org>
Date: Fri, 15 Aug 2025 13:50:57 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Nalivayko Sergey <Sergey.Nalivayko@...persky.com>
Cc: v9fs-developer@...ts.sourceforge.net, netdev@...r.kernel.org,
	Eric Van Hensbergen <ericvh@...il.com>,
	Wang Hai <wanghai38@...wei.com>,
	Latchesar Ionkov <lucho@...kov.net>, lvc-project@...uxtesting.org,
	stable@...r.kernel.org
Subject: Re: [PATCH] net: 9p: fix double req put in p9_fd_cancelled

Dominique Martinet wrote on Fri, Aug 15, 2025 at 11:01:00AM +0900:
> > Add an explicit check for REQ_STATUS_ERROR in p9_fd_cancelled before
> > processing the request. Skip processing if the request is already in the error
> > state, as it has been removed and its resources cleaned up.
> 
> Looking at the other status, it's quite unlikely but if other thread
> would make it FLSHD we should also skip these -- and I don't think it's
> possible as far as the logic goes but if it's not sent yet we would have
> nothing to flush either, so it's probably better to invert the check,
> and make it `if (req != SENT) return` ?
> 
> client.c already checks `READ_ONCE(oldreq->status) == REQ_STATUS_SENT`
> before calling cancelled but that's without lock, so basically we're
> checking nothing raced since that check, and it's not limited to RCVD
> and ERROR.
> 
> If you can send a v2 with that I'll pick it up.

Actually it's just as fast if I do it myself, if you have time please
check this makes sense:
https://github.com/martinetd/linux/commit/afdaa9f9ea451a935e9b7645fc7ffd93d58cdfed

This is a fix but I don't believe it's urgent (can only happen with a
bogus server, and while in theory we should aim to be robust to an
adversary server I don't believe 9p is anywhere near that point), so
I'll push it along with other fixes next cycle as I missed the 5.17
train

Thanks,
-- 
Dominique Martinet | Asmadeus