Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp7032484ybc; Thu, 28 Nov 2019 09:35:30 -0800 (PST) X-Google-Smtp-Source: APXvYqwEiNZ4Gmr9x84AcTbVamv+gUo4g2EW0kRYzQmItCjGKO827F2SQO3D/dP382JhYLv7Frzy X-Received: by 2002:a17:906:a444:: with SMTP id cb4mr2357217ejb.42.1574962530023; Thu, 28 Nov 2019 09:35:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574962530; cv=none; d=google.com; s=arc-20160816; b=BBhrdufN7z0SufHjB/dFPTS6/azeAsB9giyRGgjpuWqeUSxlRbGhWVFG2Rl/ulBBZl QQ5+sDsZKws/3HHYtfWxcwg4AGgOirxvdUyQnFjKjJOYE8E1EVBPs3DvBaDeiK460Vwf djn5vJjz8XebkyvwkSpakf/PEy4J6fiJECkUqSyuW1H88Ol+wcRRiuY+eiYCZuEw06VL ZzDnPsF5qmXhcEosOsAjGfyPc8VCR+K7tO+t0Fhx/L0+trV9FMcccNma+7VRG0AKrZdn npwPTXukYVS7jc3imXm94g/toZa/Fvd60z49haShf+U4SRfLOkYeI5riD0vwQSKVe7Nt pi+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=8tCNMrIvlyjN6DpBTc2cXGTzsbNxiyvpyu9AN+jCbY8=; b=FqMXIF6Pk91yGeINvmc6c5ebN+c8OH1W8/05QBlQd2sI7oGD580nWMT84Oc0dZtzKT yO1SY7EZGulH2vNlYBRhnZ5l3J4Rs3fGr/BNeZtkFLbbwPJeKaAbTvQKfGge29yK+oJC A3bEoh0BqBUUxd/sKqV4TuZB/mttW2xGywg4J+fUwFZFFtY7zvq71lSwiGT0L/O6eSGn zEickn7vSwAbpXOhFg5PSKMoye8GcRBF6/W2VQZ5oQQYkx1FbV4PDLECnGAfpzFzl6sH 3IlC/lP8DhR5iybgq4JojlaTGpV2HGnSiN9dvYgYE18cFIsEJdKbBruuI83r8vOOL3iO aBqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n8si785168edq.276.2019.11.28.09.35.05; Thu, 28 Nov 2019 09:35:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726698AbfK1Rdn (ORCPT + 99 others); Thu, 28 Nov 2019 12:33:43 -0500 Received: from netrider.rowland.org ([192.131.102.5]:57873 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726610AbfK1Rdn (ORCPT ); Thu, 28 Nov 2019 12:33:43 -0500 Received: (qmail 20969 invoked by uid 500); 28 Nov 2019 12:33:42 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Nov 2019 12:33:42 -0500 Date: Thu, 28 Nov 2019 12:33:42 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Oliver Neukum cc: syzbot , , , , , , , Subject: Re: KASAN: use-after-free Read in si470x_int_in_callback (2) In-Reply-To: <1574938260.21204.5.camel@suse.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 28 Nov 2019, Oliver Neukum wrote: > Hi, > > it is a bit awkward to complain here, as your patch tests as correct > while mine didn't, but this is a race condition. > You can't guarantee that urb->status != 0. > The kill may happen while the completion handler is running for > a successful transfer. > > I really appreciate your help, but I must understand what is going > wrong here. You are stopping the resubmit, but how could the resubmit > ever have not failed? You probably have figured all this out already, but I'll answer anyway. The code I changed doesn't race with the error condition you were concerned about. The two are independent, and it doesn't matter if the kill happens while the completion handler is running. In the case my patch addresses, the resubmit does not fail. Rather, it succeeds but then the URB completes with a -EPROTO error. The problem is that the completion handler then resubmits the URB again, and it completes again with the same error, right away, in a tight loop -- which prevents the CPU from executing any other code. The way to fix the problem is to break the loop by not resubmitting, which is what the patch does. Alan Stern