From nobody Sun Jun 21 05:33:43 2026 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C251274FDC for ; Mon, 6 Apr 2026 22:00:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.128.169 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775512848; cv=pass; b=mE/gbZlnNXffi0eP/1i5dwe5bXGZlYpvwfoTXWM1QKcTIeJPsieH8Snm0+bQfjU6c0/t9vuBDMdiZLj6AxXEWpspqNW8825RDqHsRuDtIoq9o3m2U9vCYeAq5Dxa8Wuj27LMBfL2iZ5TjiDIrQPP/s5KMmqgEPcNQ5WquQJ342E= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775512848; c=relaxed/simple; bh=AhRF60yZ5wlYEHmbfH7z43ugDhTw4ErR0cp+/TsXLy4=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=e8n1J+P+IcauuGplHT2q3th9IjOrARrzvPXtl8vM7LwVHT7RigiA3lpXzcaGqg3J8D4QH81raC7HmfPt1iI4GK2IDCjPhe0MzXG77E5LQhWNZ56kQj9Ofr9nNaVu/Oi+FbTBqUEVDo19giXFJ/Jvrp9m+HcdQd9dnVasspLba5Q= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=openai.com; spf=pass smtp.mailfrom=openai.com; dkim=pass (1024-bit key) header.d=openai.com header.i=@openai.com header.b=c6X2nHVb; arc=pass smtp.client-ip=209.85.128.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=openai.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=openai.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=openai.com header.i=@openai.com header.b="c6X2nHVb" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-79ee5037d44so58582347b3.0 for ; Mon, 06 Apr 2026 15:00:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775512846; cv=none; d=google.com; s=arc-20240605; b=G/JtztW0xlALw/q2cLAkMX/MNXZhtJWddrZl3twxEtH1m3mgLH6H7N687y2qfjRoxE CeW4ckcFEHmHgoZO9ugIrl+uKiAdc374K8iskVdFI6nH4ryM75maimPDffYqkn2Pgpsu guu6i3T60R3ET9yA0Sa2M17YJJIXcKxfyQQLiqN8ISm2ZCycDq2vIabwdqBufJDUxEky nU5y9G3w45ERoPhivf5F6llilAaEhbJqG6GJT++5FVUuIVVmjsLFTU0FJxZvv2kCRXkl gsKp6HVgM36vY6nZ1sRRf1russKkgDrOhAzuOMJibTQeb0Ke/XX7xK8ExU3CLq2JowJv t14w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=IrXmhlnDFDN3/y/XfnM5ZPPgKttgJY7jZg+IfQOG2j0=; fh=SLTllc4bb/QOiFoVbqlb3yXIekrCaRewLfG6PR1VNBQ=; b=VfwX6XIM04L9nb+XVCMrsFaGWNiqg+N+iEqu5QxZS59nXtLnD3R3YWSdOp4afyRGn+ SwSGhV71VmkQwc0r2WZkFPsH7dHyka23zLLCfc7U7fcSHOeK2NjcqzV0Tr4xRCXJfkB4 9ghVWFB33h6NAYH0ret8z5VTNOS4dtqmMrG5v1P+DnN90qnFgrjmci0y4hXU2jH/QSuU e0KY/UjLrDtOkUa5SzBDipN7XqssVJFGAYI9w9vJiXyo2/zxVbCTSx+EWlkdy4e+sDH3 DDP95siCRrTRUUBwRnaHfJRmt4WjEZ/VzrYRYZRkgbHqyug2j432/avr4YOr3A564Unf VbHg==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openai.com; s=google; t=1775512846; x=1776117646; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IrXmhlnDFDN3/y/XfnM5ZPPgKttgJY7jZg+IfQOG2j0=; b=c6X2nHVb/R0ZocumPqumAGdVuSECg1Qc374+PH5Z0sjnPDQZKwNuHTTdWFNZOuwhwI YK4O3Wi9lShXzDqRcGPdNLi9XogXoWIEDJUJV9J5QwnBPRFXRjjDKxUOm4kZpSDE+2V1 l7zvpuHnRLuwuwbprEiuI6tbZmEx+uCyTp2x4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775512846; x=1776117646; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IrXmhlnDFDN3/y/XfnM5ZPPgKttgJY7jZg+IfQOG2j0=; b=XssRrShPsZWtJzLl8MmCZZiiMtm2m/Gx8iFpJKosXiMKvAx8UGppTJE0pCnv7xX6n3 GTgLvGJav4HVLCYYHsXv9vQwNa5cU8l6Tb4WezKoEMD15FqZD4uIjOj7sOYm8YaX61rY 9vAZmz4myqv3pdKSOoLuwg4lU3FyKcKov9u6SuvPWGTKcBLQM4zErLTkb27qFaQVkunj 91JMCzeOd8YT/WzOyjVnWk5Vvysl5XIxr/N93ZD7G1BHGU8ocrtTWegiVGQNcX8pSnds obHg0MzOYw3nMRZkfubTniUrIFiT5rfFLwM8MybIN2jlQEA5cqDTAmP74ZSO3mAWLeJf A9Kg== X-Forwarded-Encrypted: i=1; AJvYcCUwIc+uORU8R2KT4YAVmA7DosmPJ6tRHU54YFr4h0lrvAPvJ3K3pT37HFlPifqddEvN1nSsJaZec/WENM0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx7D7sdFZEAp/b9SEEQPkojrpwGbjlkdV+FoC1+rD8XvThBXjfk KJdZN5Ga++hZjhXtvxSRgC10FUWBQUOkCuuaGo1BVNXyarUx/RjZagmL2yff6+KNVjbTWOqvNIP Xl4p5Kh0YnltQu4gs99q6Ni9wuZ4gjq4Iw6ht/Lsy0Tf5cszj9CHKYlCaDQ== X-Gm-Gg: AeBDievTATYUPGf7PkcZkWGCzo5Eu/JAbm9aURfeSWG//EhkwbwA9AZrigILzr4B9Nm uwg2zAVxQSu6Ikb0/GOzIkzlXHjG2U3ferKfkCYwJT4vFdq6Gpn/l2P3Mf2x5Q2iRipr0HG5eyB 8dCnFgxxoosQb1YnlW0xO0cnf9sgBfGJO6de9zBUuMLNPF0v0Pil4cqt3l9jlYu1vCYoz3fYl4I Uv+WXXF/xRM6O3CH4E4Sb0AemSONHi43g/51shaWb4DxtybGV6IjPp3enluFubpkhm3nMyo3Bqb gK/OLFegcj01Ms/8mZs9AX09XgobjtHlR1yCgCEjEqQzf4p/TCVlFG5oNfy1hUiHHmeHtbpUGPY 40apj8wLeppjfzoN3QROECyV3nwxPVMm5WRg88XmPfiUsyuKjOvOlzS4sXFS94o8m7Ilt+LOJ/A == X-Received: by 2002:a05:690c:9c0a:b0:79a:b409:b5e0 with SMTP id 00721157ae682-7a3b8501632mr145564957b3.0.1775512846515; Mon, 06 Apr 2026 15:00:46 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Sina Hassani Date: Mon, 6 Apr 2026 15:00:36 -0700 X-Gm-Features: AQROBzDj1uhH1bQgWEj0c8LOPX5fqDnQKRUjEk5oKgfET8whs1RVLalE8TLXmm4 Message-ID: Subject: [PATCH] Fixes a race in iopt_unmap_iova_range To: jgg@ziepe.ca Cc: kevin.tian@intel.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Aaron Wisner , Sina Hassani , stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Bug: iopt_unmap_iova_range releases the lock on iova_rwsem inside the loop body when getting to the more expensive unmap operations. This is fine on its own except the loop condition is based on the first area that matches the unmap address range. If a concurrent call to map picks an area that was unmapped in the previous iterations, this loop will try to mistakenly unmap them. How to reproduce: I was able to reproduce this by having one userspace thread mapping buffers and passing them to another thread that maps them. The problem easily shows up as ebusy errors if you use single page mappings. The fix: A simple fix that I implemented here is to advance the start pointer after we unmap an area. That way we are only looking at the IOVA range that is mapped and hence guaranteed to not have any overlaps in each iteration. Test: I tested this against the repro mentioned above and it works fine. Cc: stable@vger.kernel.org Signed-off-by: Sina Hassani --- drivers/iommu/iommufd/io_pagetable.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/iommufd/io_pagetable.c b/drivers/iommu/iommufd/io_pagetable.c index ee003bb2f647..965fa23df103 100644 --- a/drivers/iommu/iommufd/io_pagetable.c +++ b/drivers/iommu/iommufd/io_pagetable.c @@ -812,6 +812,7 @@ static int iopt_unmap_iova_range(struct io_pagetable *iopt, unsigned long start, iopt_put_pages(pages); unmapped_bytes +=3D area_last - area_first + 1; + start =3D area_last + 1; down_write(&iopt->iova_rwsem); } -- 2.43.0