p9_xen_response() takes the length of an incoming response from the ring
-- the first field of the 9p header, which the Xen transport reuses as
its framing header -- and uses it to advance the consumer index, but
never checks that it is at least the header size or no larger than the
number of bytes the backend has actually produced.
A malicious or buggy backend can post a response whose size is smaller
than the header (for example 0). The consumer index then never advances,
so the response work re-reads the same ring contents instead of making
progress. In testing this raced with the teardown that the malformed
reply triggers and dereferenced a freed p9_client:
9pfs 9pfs-0: Wrong req tag=ffff
BUG: kernel NULL pointer dereference, address: 0000000000000060
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5 #6 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
Workqueue: events p9_xen_response
RIP: 0010:idr_find+0x4/0x10
RSP: 0018:ffffbf5d80063de8 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffffa229c21195a0 RCX: ffffa229c2400000
RDX: ffffa229c11c2200 RSI: 000000000000ffff RDI: 0000000000000050
RBP: 000000000000ffff R08: 3fffffffffffdfff R09: ffffffffffffffff
R10: 3fffffffffffdfff R11: ffffffff87a60e80 R12: 0000000000000050
R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000100000
FS: 0000000000000000(0000) GS:ffffa22a7661c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000060 CR3: 000000003ac34002 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
p9_tag_lookup+0x2b/0x90
p9_xen_response+0x17c/0x2e0
process_one_work+0x16a/0x3a0
worker_thread+0x172/0x2e0
kthread+0xdd/0x110
ret_from_fork+0x18b/0x240
ret_from_fork_asm+0x1a/0x30
Modules linked in:
CR2: 0000000000000060
---[ end trace 0000000000000000 ]---
Reject a response whose size is outside [sizeof(header), queued] before
using it, matching the validation the backend already applies to
incoming requests.
Fixes: f66c72bea129 ("xen/9pfs: receive responses")
Cc: stable@vger.kernel.org
Signed-off-by: Yehyeong Lee
---
v2: use dev_warn_ratelimited() so a backend that keeps re-triggering the
event channel cannot flood the log.
v1: https://lore.kernel.org/all/20261005021157.207947-1-yhlee@isslab.korea.ac.kr/
net/9p/trans_xen.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index f9fb2db7a0663..0ea8e17725c24 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -200,6 +200,14 @@ static void p9_xen_response(struct work_struct *work)
masked_prod, &masked_cons,
XEN_9PFS_RING_SIZE(ring));
+ if (h.size < sizeof(h) ||
+ h.size > xen_9pfs_queued(prod, cons,
+ XEN_9PFS_RING_SIZE(ring))) {
+ dev_warn_ratelimited(&priv->dev->dev,
+ "bad response size %u from backend\n", h.size);
+ break;
+ }
+
req = p9_tag_lookup(priv->client, h.tag);
if (!req || req->status != REQ_STATUS_SENT) {
dev_warn(&priv->dev->dev, "Wrong req tag=%x\n", h.tag);
--
2.43.0