netdev - Re: [RFC] USB: ipeth: race between ipeth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <22bd911b-b328-4536-92bc-e5d89d0eb9ab@suse.com>
Date: Tue, 20 Aug 2024 10:21:13 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Foster Snowhill <forst@....gy>, Oliver Neukum <oneukum@...e.com>
Cc: netdev@...r.kernel.org, linux-usb@...r.kernel.org, gvalkov@...il.com
Subject: Re: [RFC] USB: ipeth: race between ipeth_close and error handling



On 01.08.24 21:42, Foster Snowhill wrote:
> Hello Oliver,
> 
> Thank you for the patch and patience!
> 
>> ipheth_sndbulk_callback() can submit carrier_work
>> as a part of its error handling. That means that
>> the driver must make sure that the work is cancelled
>> after it has made sure that no more URB can terminate
>> with an error condition.
>>
>> Hence the order of actions in ipeth_close() needs
>> to be inverted.
> 
> The change looks reasonable to me. It's been a while, but do you perhaps
> recall how you stumbled upon this? Was that a proactive fix, or was it
> in response to an issue you (or someone else) encountered? Basically
> wondering if this is something I could test/reproduce.

Hi,

sorry I was on vacation. I think I looked at the driver because of
an unrelated patch and saw this issue. That bug type is not exactly uncommon.

	HTH
		Oliver