From nobody Sun Jun 14 23:05:14 2026 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (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 8B41F304BDF for ; Mon, 6 Apr 2026 23:07:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.128.181 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775516836; cv=pass; b=UkQKg41xb4ruWEiSY1Qz5bkEwIUA7P1tRzLPr7WnMD4FHjrBh+4TaecnuctfxddThFqf7RALCOdfdZrE66csEJoGAoEi/ztb8Oy0yE2+IIEEYP5ip3vKRfFEJhEzqr/+s/9cnIfIoMiBvXjUvjHQRcDFl6StNZMqRZwW9uC+dZE= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775516836; c=relaxed/simple; bh=CbERZQC17/1PoShTGE/NPjrUpQC94UvYfWpdVNsODS8=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=Z2nJujpdIJEIHGvqN4kf60OIVo01gNSwRkOVSm+/ls/nNNFmxN/eqagXI/NYq288TouAWmTqleG+3SLb2H9X863QZ9ivEZOpSMdpQsS6LmtYq7/Ja61bSYB7IjvBjnpFAttE9MNjzoG1KAJLm2ITqJyEvskNLq3oXy/+C8Whi0o= 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=H9pLV6+V; arc=pass smtp.client-ip=209.85.128.181 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="H9pLV6+V" Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-79ee5037d44so59229247b3.0 for ; Mon, 06 Apr 2026 16:07:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775516832; cv=none; d=google.com; s=arc-20240605; b=jtTMy+7R52N1t1UciNF/hagT7ZQyqSsZxd5JHEBuaXQHE+oF9bfZp0dMfcqmj+n6K4 NjyEnyxfGeRPnhr4igmuzXqfiE0YOQAYZb6fgMfVXOOhSSDynu7aAz3v2ZgjbVj+59mh uChoBVAg1a+qz5OkXoYGLpTECfCC7ECyBfYO1byKjf/3+E9ODR25V0VEvT4ODiItfLDI x6p58gdsPxj55nI7RWiA8HEO3vnT5uCKfEVXbaJRNzH/cfYy2IlpbFa5hqRSjaHYfNNW 6UCzK3P2lw2IhDuaBjD/D4DJRfbmM1mgtgMGCgWrk4TQd4lgHI5ypsITyQUwfiw6YQDz hIhw== 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=L3Od81lft/9iTZV5t8cEzGB2LzR86DDU9DJfU96Ox18=; fh=g8LyQQNTeTT71Pik8BbqE4hPhMjPlvEwEj1Yhw1RpgE=; b=MU5qvXitYBAmOHvX+d0p0nkU+rmDGp7h3StX5Tlun0KNWLfxWUuhrgi9pZTdgJHOK0 tazsauyN8kwN43c0jJklFJZE+MkZ6j8gw4hWp9fz4+DfDUV1L8y9t9HeE+xBjZAynaMF 0jTYYg5GKORm/5RcuIgenSXwJZ+jSxXGW8NHgiCwpRHKckRqWg/5p5Wd5huZ+cMNdFDe 54vCBtgmuDvVLZxOy7YeiLseCMtPrQgbv1+q+FYujFHbxUcQr39Gb/OGMxKUaX/ntjgB ZM+ZYLfAV1SfCkYS1F7L7Z/LcMt9hHDrx8DuDMHyeICMQuuHHzk4TennLpso9Kltj0F/ sxQQ==; 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=1775516832; x=1776121632; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=L3Od81lft/9iTZV5t8cEzGB2LzR86DDU9DJfU96Ox18=; b=H9pLV6+VbAWRwR51pZS+4P62w1Ygb07yFuj/Lv/7+ddzt+90UJWncpxO8zf0r3htOe o7u/0c3VQHmuXdmZWZ/CpjyoldRy9Lq9wg2jGFt/1urVaBM3T5CaIk1H2xIqw6FQbRGL 1jOZ/W5Jw0ieCLR6AVme34aHnqjeXs1M5meqA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775516832; x=1776121632; 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=L3Od81lft/9iTZV5t8cEzGB2LzR86DDU9DJfU96Ox18=; b=JipMgNVhdzHtI2DFe8Wb+/Mvpu5X82Ze1NBTIVSuiM7+g9A5BzcR9BtA8l8oSbH5Ys iOjiURS10Sz6dL6AVnDhfVsN//ZM7S/Ly4CfCZpxfaaldVfIA2hAkX5WnoBwzVJ2UVsb HdRAavx2gA5vIEVZIyeZrnTwUTWe2xC3Vd+bYvh+kZMSnByOEqgc0xBCYEd1I3HUI9BV tQF9gMebu7ezgRBo3DFLnsxLRI2J1fdhGme9nBJRN9pd776CWXqvlKXK+0dYzQzjO59A 52IGygEMNRSZdjxOl0lY/0wqx53PxGwZqDJMtODSXcffIbbNTFALABt0yfTVe05Usx5v ggUQ== X-Forwarded-Encrypted: i=1; AJvYcCVPnDWx4MO89o7GPO39ZLuabuaoB5VBEBPrOCqAJNSv92rD1xWCUEwy0pb1ubMYcyArRHHJafj4rBn6SYU=@vger.kernel.org X-Gm-Message-State: AOJu0YzOqKRZMKTJ7OWVJ3F4oWJAFTn61UMht/E8lGh+8XGpLjeGMuj/ ImRxq9uTUW86k33DPYytouyzH5rEg1Y+pFWOLHgC5PBVEc9mJ5+dOHSW+510OiHGhFXTT2/IdFK kYT50yTHW7f0e43S1VpmjpmWmBeIE8E3HQ1cmXc9miA== X-Gm-Gg: AeBDievw9Cpb9KUt2Uzv3EeXfrvfY7cGXBXAXgR/wmvPdvhmskmcA+6h9AuH92bNgQa AQ+YzbKFj07gMTKUv6vRf+HAU+2DDY9n+Ihrz0JZSMuC6u43uXXr3ZZgPhd4Rv9wMMJeCexRzea ggxxEGTZh3VqNDkohdTYffxabY+4unqBgbJcUmUtf4xXhCLCD9CIvxts3tZRSQOIyWuBvuqmDwd MvT7BQAoKimczR+0vMTtwC8BPAqpdvgl9FYEUW8zVkPrLPfuN7KmUm6pwGmdcMXX0ZX6FpmTAFA 2srEI/8O7G1lORNO0LW1cOPY1CjbFQSEA0uv+bEbKl+3+Ku7vCKnwgLZjT2g4sQgbkVqUhMa/oI y62lpw34x5iChCw7h7FKKVSbY/b1nHT2U6Lh2+t4yLc4f6mHoNMX/aRMFkA+bNEk= X-Received: by 2002:a05:690c:f06:b0:79b:82b2:f284 with SMTP id 00721157ae682-7a3bdd8177bmr137403337b3.17.1775516832586; Mon, 06 Apr 2026 16:07:12 -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 16:07:01 -0700 X-Gm-Features: AQROBzD2O2l_CHT8-ax6fGxbh3AX0FfbqXbleB2YomgxanwhD99Y69vm8oR3hmM Message-ID: Subject: [PATCH v2] 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 , 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 | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/iommu/iommufd/io_pagetable.c b/drivers/iommu/iommufd/io_pagetable.c index ee003bb2f647..c69af341219a 100644 --- a/drivers/iommu/iommufd/io_pagetable.c +++ b/drivers/iommu/iommufd/io_pagetable.c @@ -814,6 +814,15 @@ static int iopt_unmap_iova_range(struct io_pagetable *iopt, unsigned long start, unmapped_bytes +=3D area_last - area_first + 1; down_write(&iopt->iova_rwsem); + + /* Do not reconsider things already unmapped in case of + * concurrent allocation */ + start =3D area_last + 1; + if (start < area_last) { + /* Overflow. IOVA ranges do not wrap around so we c= an + * exit here */ + break; + } } out_unlock_iova: -- 2.43.0