From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 539A31F5834 for ; Sun, 24 May 2026 16:46:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779641201; cv=none; b=fatoyQAM2XhyopB0oq1/rC0kaDgjn2B+Q2v9x3PQuqkODePXdewRsSXGPsuHIpiiYYN3tfmQi1RMsQ6bvv8g+ZkDA3ZOp1r8tCRBzZuSc6ARXfUH1k9cSMwtI9+yQD/7UronTrGCkStX8TwqolSkqitVEAinr73iq6ASU7CT/aY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779641201; c=relaxed/simple; bh=j2j0D1jOjd4UBCrhIhr50v4K6cW+B+G+YjTRbqpq6RA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SyepGLZZO5DwgXE+fIUEM5J4IROzhxoLHzozNOlSPDqqFiH88DQ1AGp2vQo7Rqh1MD1Z8tdgCr52GrhUDG1S9vVE39YVgGzqHjOquzyXv9Cq9gQ1HwDeldNheuRydDzBK8YWTKgeUEm+YJJ+MHqrKAFuthIoYlJ45aAB8MVRYd4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lB7PAhTX; arc=none smtp.client-ip=209.85.167.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lB7PAhTX" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-5aa0da74eaaso8984964e87.1 for ; Sun, 24 May 2026 09:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779641198; x=1780245998; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=hLzR3htq1atAmvb17/pEVQjmT80azUTFF79GXEig94U=; b=lB7PAhTXlgHBdE96I1VBKRsY1qAG9+cj+m+HVZ4Ihs1AEURWGMHRWYsASjSsVjxYKv j45gNvYdm3QuVvPT2OOe8Gi4jjIZUp+7VBjd4W79r5O/4Hc8Ed6ChBoCPvK6xsdhfnV+ CDFXiGzwpcdjLSNuiYFakfLSX/S57z8Ruccb5zx4NIbcRXbyqOGRcw6+l0m2t4r7T4bo yetc+rGFV9lBTn6jD2GYZH2aVeijBaTF0dEvZ+fSL0fQkcQ9KPqkagkA2qNs3JPmcIQj +6P1iuNNc3PiAj7EqYXzfJmkIj3jiajKhtcY16qe3eBViAUoB86N85qqb8j078Aey6pl JEkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779641198; x=1780245998; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hLzR3htq1atAmvb17/pEVQjmT80azUTFF79GXEig94U=; b=LsOfhJPpQogxXPzLL2lbwsJlrAIoxERym56Mlrtjbxk2wcHpu9XsSX63m2/lp6nE1m o9wvkiv0h9OVRl1Y/ejG3Irpfx5UfTYxtwydF2Vy5pNcfD0JX/TDFu8qwy6soq172zBu d63WzUutYg/zlxGpScirf0r/zpQxbxNLVwOqmgkx+axodP6qlWgc72RUn9GBFppqBO85 4jQZ2r6icpK2xpprYLQ3kKsHV+8Yn7S9yX2fjUbGRT/ly+Og+Uv0zvo4TAlaL2Ups7YA HBPN7OcfRMFNV0HdFgh2NIHKuKGQSITSzBPjROMv7gTShP6o5TDx547n4hl4aSiFD2YH Zp2Q== X-Forwarded-Encrypted: i=1; AFNElJ9FJbXMmPLjFMdPcm/A+gmO0V/V/sURpzaDkQRykSKDgEkOpdCB0iVy8VYIsjm7tUZi2oKkYBaeHPRYicA=@vger.kernel.org X-Gm-Message-State: AOJu0YyGfsoGquLRUsyj44rEgQopjCb+hDfeWxGpAfs8HGvBOQob5ecF P0Mv7Mvh8D+tuI44d8wo+apgXZxglwD+9zg9iXCGdeurLnu4vEG5oVYlZFQwgA== X-Gm-Gg: Acq92OGMgETxUfPLM9YWr/Y9KmD9eZF5hfQqk0pe33kvp8vSMbaXdGdbnjI17CTtvQC FT9Wy0jz/yyx5ZCKz2bj7wl4XqfhSv2+KZJQIloIV6C9RGe+5JgfwGKFXwqPLAnaPYtU8yjXTjb U4/nFU2FFn7vNQJeaZhGMPseVD06rHEkBZq5d+S6PeyMIGUPheuLANakwFsmsTML/EePTjXaO7E zCEUddaUzRlbYzo2CE+V3iF6o3MW9ZJP44o6zSNaG5SmV8wmCvBB79wm5iwh4ww/OhgCAXVIzrG tOs3wV5I12lZ6WdrZBl4yfs0zxuyDr9C1aqdlmhWQA2ZvswB/kKqG+HjOQKPsOQSg6QiwylZ/sz ZQrhWUF0TIocrv6ytEu2uYmsOqzqptZeKBOSjWyM7gN5xwyd0oEj5ddeClGqRTjpEIlGijWIws3 GrIOMH1ektS1WsdJhgRnM9FoN3d8VaQ/je X-Received: by 2002:a05:6512:1444:10b0:5a8:6def:7e38 with SMTP id 2adb3069b0e04-5aa32308639mr1895271e87.15.1779641198193; Sun, 24 May 2026 09:46:38 -0700 (PDT) Received: from foxbook (bfk48.neoplus.adsl.tpnet.pl. [83.28.48.48]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5aa32cbabd1sm2006938e87.34.2026.05.24.09.46.36 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 24 May 2026 09:46:37 -0700 (PDT) Date: Sun, 24 May 2026 18:46:33 +0200 From: Michal Pecio To: Alan Stern Cc: Joseph Bursey , syzbot , gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [usb?] KASAN: slab-use-after-free Write in iowarrior_write_callback (2) Message-ID: <20260524184633.405c4b3c.michal.pecio@gmail.com> In-Reply-To: <69c60a2a-68d2-48b0-8236-b80cd6b602cf@rowland.harvard.edu> References: <6a0ce39b.170a0220.39a13.0007.GAE@google.com> <32c79569-8001-48d2-9675-b38b1670f285@uci.edu> <20260524103053.308501de.michal.pecio@gmail.com> <69c60a2a-68d2-48b0-8236-b80cd6b602cf@rowland.harvard.edu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 24 May 2026 10:45:39 -0400, Alan Stern wrote: > On Sun, May 24, 2026 at 10:30:53AM +0200, Michal Pecio wrote: > > On Fri, 22 May 2026 13:38:40 -0700, Joseph Bursey wrote: > > > Hello, I believe I have a reproducer for this bug using a > > > combination of syz-execprog and eBPF programs. > > > > Hi, could you check if this patch (compile tested only) fixes it? > > > > I admit I'm not an expert on USB core, but I see nothing _reliably_ > > preventing URB submissions after usb_disable_interface(), which may > > be the root cause of this bug (besides the driver sloppiness for > > which separate patches have been posted by Johan Hovold). > > The general attitude has been that it isn't the core's responsibility > to recover from bugs caused by drivers. Rather, it is the > programmers' responsibility to fix the bugs properly. Well, there is also the attitude that core doesn't do crazy stuff like removing endpoints and resetting or suspending devices with URBs on them, so HCDs don't do much to handle such anomalies. https://lore.kernel.org/linux-usb/5f7a69d7-87fc-436b-a3c9-b9d4fc1a5c17@rowland.harvard.edu/ Combine the two and a buggy driver might take down the whole bus. I'm inclined to see the existence of these usb_disable_endpoint() calls in various places as an admission that USB subsystem has never really placed much faith on all those class drivers. Maybe rightly so ;) I noticed commit f9a5b4f58b28 ("usb: Avoid use-after-free by flushing endpoints early in usb_set_interface()"), which sounds a little scary. > On the other hand, it won't hurt to add some code to the core for > detecting and reporting buggy driver behavior, so that the > programmers would know about it. Current situation is that core removes some 99.9% of all URBs before calling disconnect() or performing aforementioned HCD operations, so recovery paths (if any) aren't getting much testing and one could write a successfull driver without even knowing that usb_unlink_urb() exists. But the remaining 0.1% of time things like this syzbot report happen, and back when the number was more like 90%, the remaining 10% was apparently quite exciting on the xhci-hcd side too: https://lore.kernel.org/linux-usb/20180721105509.hjocon6ngk2liwo4@debian/T/ If the URB elimination ratio could be brought up to 100% with a small tweak I think it's an attractive prospect, hence > > My patch tries to fix it by updating ep->enabled under a spinlock > > which will be held while checking this flag on submission attempts. > > I also suspect that more UAF in sloppy drivers is possible due to > > usb_hcd_flush_endpoint() failing to wait for pending BH givebacks. > > usb_hcd_flush_endpoint() only guarantees that the HCD is finished > dealing with any pending URBs. It is not meant to guarantee that the > URBs' completion handlers have run. Fair enough. > > It seems that dummy-hcd doesn't use HCD_BH, so this shouldn't be > > a factor here, but it could become an issue on real hardware. > > Do you think it would help to provoke some exotic bugs if dummy-hcd > did use HCD_BH? That would be an easy change to make. Not sure, besides the obvious possibility of a BH completion being missed by usb_hcd_flush_endpoint() and running after disconnect(). Also not sure if syzbot would catch those cases if BH is enabled. Regards, Michal